[Grace-core] Multiple inheritance & module inheritance

[Kim Bruce]

Maybe I'm missing something, but this seems mainly to be an example of why family polymorphism is very tricky to get right.  Your example of overriding a in a subobject of module is clearly unsafe.  Any reasonable definition of family polymorphism would ban this.

In fact, I think it would be a bad idea at this point for us to incorporate family polymorphism.  That is, one should not be able to override a class definition in "module" in any subobject of "module".

If one did want to allow that (and again, I don't think we should), then one would have to insist that the new class extend the old in that it would have to have an x def in it.  There are rules for safe family polymorphism that are available in various places, but again I don't believe (at least at this point) that we should attempt to support family polymorphism.

So suppose we were to ban family polymorphism.  Is there still an issue?

I can imagine that there are situations where we might lose the "statically-known" property, but I don't see the problem of inheriting from a class in a module (as opposed to overriding a class in a module).

Again, help me out here in understanding the problems.

Kim



> On Mar 15, 2015, at 6:15 PM, Timothy Jones <tim at ecs.vuw.ac.nz> wrote:
> 
> On 10/03, Kim Bruce wrote:
>> 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?
> 
> So, for something to discuss tomorrow, here's an example of how
> 'statically-known' as a requirement on inheritance doesn't really make sense:
> 
>  def module = object {
> 
>    class a.new {
>      def x = 1
>    }
> 
>    class b.new {
>      inherits a.new
> 
>      def y = x + 1
>    }
> 
>  }
> 
> If the module is inherited through delegation/cloning/whatever mechanism, the
> inheritor can override the class 'a', with changes like removing 'x' or not
> being inheritable at all.
> 
>  def module' = object {
>    inherits module.clone
> 
>    method a {}
> 
>    b.new
>  }
> 
> So 'a.new' is not statically-known, and this inheritance is not valid. All
> methods have to be defined in objects, so the only things that it's possible to
> inherit from are classes defined inside of methods or blocks:
> 
>  {
>    class a.new {}
>    class b.new { inherits a.new }
>  }
> 
> This is something the 'let' proposal was able to solve: classes can't be
> overridden, and so they can always safely be inherited from.
> 
> -- 
> Tim