[Grace-core] "Classical" Inheritance for Grace

[James Noble]

> Comments embedded below.

replies mostly after the comments.

> This seems to work fine, and one can always build up an object factory if you like that style instead:
> def pointFactory = object {
>    at(x,y) -> PointType {Point.new(x,y)}
>    atOrigin -> PointType {Point.new(0,0)}
> }

right...

> Depending on other decisions, inheritance might be easy or hard from this.

yep.

>> -------------------------------------------------------------------------
>> 
>> * Stability / Static
>> 
>> We'll need some kind of defintion of what is a static or stable
>> (Scala's term) reference to a class. 
> 
> Is this supposed to replace definitely statically?

it's supposed to define "definitely statically". To  flesh it out.

> Examples would help here!
> I'd worry about this.  Can you illustrate with examples?

later

>> -------------------------------------------------------------------------
>> 
>> * Modularity -  

> With the equivalent of "definitely static" we should be able to infer the types of all classes and hence never write them down.  However, we could have an option of being able to write them if that seemed useful.

yes, but we need to do a whole-program analysis, it's not modular.
The nominal people like this, because when you get a class, you have
the whole of the class. Putting in classtypes makes 'em modular:
you can check against a Grace type, not an object's implementation.

> The problem with Scala is that to the student it is hard to know when you write List(3,4,5) or new List(3,4,5).  It's definitely nicer to have a single uniform syntax.

so this is an argument against having a magic apostrophe (like "new") to create objects.
People can alway write methods to get List(1,2,3)... 

>> If we can agree on the basic semantics, then we can fight about
>> names...
> 
> I think it is probably worth keeping the distinction between classes and factory objects, even with the similarity of syntax when invoking them, but I might be able to be persuaded differently.

well the question is do we have both or not?

>> -------------------------------------------------------------------------
>> 
>> * Multiple inheritance 
> 
> If we go down this path (and I'd rather not if possible), we should be very careful.  Everyone who has tried multiple inheritance has run into terrible problems.  Show me the examples where we need it and can't find a work around.  It's one of those great obvious ideas whose flaws show up when you actually try to design them.

sure.

>> -------------------------------------------------------------------------
>> 
>> * Initialisation:
> 
> Keep in mind that we don't have default values available (e.g., no null), so this could be tricky.  Perhaps this is something that we could encourage but not require.

indeed. I think being gradual/pluggable is the right thing here.

>> -------------------------------------------------------------------------
>> 
>> * Cyclic definitions / placeholders:

> I don't really see the need for a special syntax here.  If the defs make sense the object identity will work.  I.e., we can create two nodes that point to each other by something like
> def first = Node.new("a",second);
> def second = Node.new("b",first);

only if we have placeholders or something. Otherwise, there is no "second" object until 
we run the "def second" line which happens after the "def first" line...

> That should work without difficulty as long as the constructors don't send messages to  the second parameter.

it will work with placeholders etc.

>  In my opinion all defs and vars should be treated as mutually recursive.

there's a difference between mutual recursion through method names - which we want -
(letrec rather let)  and mutual recursion between objects in defs. 

> My preference would be for the third option, but I believe you are right:  I don't think we need to decide now.

well I think so - not sure who else is convinced

James