Re: Do interfaces make sense in multiple dispatch languages?

Quoting Isaac Gouy <[email protected]>:

> Was the motivation to remove interfaces from the language or to add
> multiple inheritance (of state)? 

They are two seperate issues that I mixed together. I will try to seperate them
and then explain how the two ideas mix together:

1. What to do with "interfaces" in Nice

I think that the term "interface" and the phrase "implements interface" are both
very confusing because they do not match the underlying abstract model of the
language. In Java, we can say that an interface introduces a type with a set of
operations defined on that type; the set of methods is the "interface". In Nice,
all we can say is that an interface introduces a type; it does not define a set
of methods. That is why I suggested to replace "interface Y { }" with "type Y"
and "class X extends Z implements Y { ... }" with "class X <: Y" (read "class X
extends Z and conforms to type Y").

I don't think it makes sense to call a Nice interface a "trait" because a trait
is a group of method implementations encapsulated "in" the trait, whereas a Nice
interface doesn't contain any methods. As far as I can tell, interfaces, traits,
and mixins only make sense for single-dispatch languages, especially languages
without open classes.

2. Whether to implement multiple inheritence of state.

Given the other (proposed) language features it seems it would not be too much
of a stretch to support multiple inheritence like I explained in my previous
email. But, I can't say whether it is a good idea or not. 

3. Mixing them together:

If multiple inheritence was implemented then there doesn't seem to be much need
for having a seperate concept of interface; an interface would basically be just
an abstract class that has no fields. "class X extends Z implements Y { ... }"
could be replaced with "class X extends Z, Y { ... }" and "interface Y { }"
could be replaced with "class Y { }". 

If there is not multiple inheritence then it is necessary to have the equivalent
of Nice interfaces but I think they should be renamed to "type" or something
similar.

Actually, with multiple inheritence it makes sense to have a "interface" or
"type" construct if you were planning to distinguish between types vs. classes,
and subtyping vs. subclassing. For example, if you wanted to support "class X
subclasses Y { }" where X inherits everything from class Y but without meaing
that X <: Y.

The more I think about this the more it seems I am suggesting that the Nice team
re-implement Cecil. We should make a language comparison between Cecil and Nice
to see what the advantages of each are. 

- Brian




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn