[Grace-core] Multiple inheritance & module inheritance

[Kim Bruce]

I guess I don't see a problem with the example as it is now written (though the hinted extensions might raise flags).  The example seems to be statically typed, so I'll assume that.  (Let me know if you mean something else here.)  The overriding of hello seems fine as B extends A.

The definition of class foo includes a definition of A, while bar, inheriting foo, has access to both A and the newly defined B.  My understanding was that, like method names, type definitions are assembled before any initialization code is executed.  Thus when the initialization code for bar is triggered, it first executes the initialization of foo, executing hello, which returns something of type B -- which doesn't seem like a problem to me.  There is no initialization code in the definition of bar, so we are done.  ... and i don't see a problem.

Reading between the lines, I'm guessing that you are worrying about foo and bar both being defined inside another object (call it baz), and that we could define another object by inheriting from baz and then overriding foo. (This seems to be leading us to "family polymorphism" kind of issues.)

Is that the concern?  If so, could you provide a full example that shows the problem?

If it is something else, please show that as well, as I am not seeing the problem.

Kim



> On Mar 9, 2015, at 4:17 PM, Andrew P Black <andrew.p.black at gmail.com> wrote:
> 
> Michael's example of the type issues (from http://homepages.ecs.vuw.ac.nz/~mwh/types.txt)
> 
>> class foo.new {
>>    type A = {
>>        x -> A
>>    }
>>    method hello(a : A) {}
>>    hello(...)
>> }
>> class bar.new {
>>    inherits foo.new
>>    type B = {
>>        x -> A
>>    }
>>    method hello(b : B) {}
>> }
>> 
>> The "hello" method must be attached to the object at the
>> start, including its type annotation B. B relies on A. A is
>> in foo and must be inherited. Inheriting foo executes
>> "hello", which will be the overridden version.
> 
> This seems to me to illustrate nicely why thinking about inheritance as a dynamic operation is not the right approach.   Both A and B are well-defined and not changed by inheritance.  So why is this code problematic, from a sematic perspective?
> 
> Maybe Michael didn't intend for A and B to be synonyms?  Even if they are not, I still don't see a problem.  Sure, the current implementation in minigrace doesn't handle this, but that's true for a lot of things!  
> 
> 	Andrew
>