[Grace-core] Multiple inheritance & module inheritance

[Kim Bruce]

OK, let me try this a second time.  i think I'm starting to get a handle on the problem.  One issue is that -- coming from a statically typed world, a lot of what is allowable in a dynamically typed world makes little or no sense to me.

Let's take Tim's example:

 def module = object {

   class a.new {
     def x = 1
   }

   class b.new {
     inherits a.new

     def y = x + 1
   }

 }


 def module' = object {
   inherits module.clone

   method a {}

   b.new
 }

This code is clearly problematic.  If would also be problematic if we remove the inheritance and define b as follows without inheritance (assuming we made a's x public):

   class b.new {
     def y = a.new.x + 1  
   }

The definition of module' that overrides a breaks b in module' for similar reasons as Tim's original example.  So, without some stronger restrictions on inheritance, it will be vulnerable to the usual incoherence of unrestricted overriding of methods breaking code that depends on the structure of the original.

So do we give up and allow any inheritance (perhaps inserting run-time checks when these are composed in order to avoid overloading methods in ways we consider illegal)?  We could then define a static type checking dialect that did not allow such things.  (Perhaps that was James' suggestion from last week.)

If we decide to go that way, then the question is what does statically-determinable look like in that statically typed dialect?  Overriding classes inside objects is pretty complex.  In my previous work it required type-checking everything under the assumption that anything could be overridden, which adds its own complication.  Our no overloading rule may make that even more complicated.  Hence I'd rather come up with a restriction that doesn't allow classes to be overridden, even when embedded in another object (as everything ultimately is).  To treat classes uniformly, that probably requires us to be able to annotated methods that return objects so that they can't be overridden.  Perhaps they could be annotated as "inheritable", and classes would automatically correspond to object definitions whose constructor methods are "inheritable.  

Presumably the annotation would be lost when passed as a parameter or assigned to a variable, but I'd need to think about that more, and any other complications.