HaloO,

Luke Palmer wrote:
>  For now (because of this example, in fact), I'm inclined to change the
>  proposal to "please don't design the language to prevent a module from
>  implementing supertyping".  I think disallowing reopening of roles
>  will prevent that.

I might not have formulated it this way but this was my intent
from the start. Since classes constitute types and are partially
ordered for dispatch purposes one way of achieving it is by

   class Num also does Complex
   {
      method re is rw { return self }
      method im is rw
      {
         return new Proxy:
             FETCH =>  method { return 0 },
             STORE =>  method { return new Complex(self,0).im };
      }
   }

This actually looks better because the .re method has a more
natural implementation. In my superrole code I had a { return
self as Num }.


>  Maybe we allow reopening of roles, but new method declarations have to
>  come with defaults; that way you are not (as above) invalidating
>  existing objects, just adding behavior to them.  That is a tricky
>  issue, though, because such definitions might add conflicts and
>  invalidate those objects anyway.  Maybe more-recently added methods
>  have less priority than older ones.  That stinks.  Hmm.  I need to
>  think about this.

No, errors should be blamed on the role that does add the parent
relationship. That is a name clash with an existing method further
down the does-hierarchy should result in a compile error for the newly
created role. Since the complete does-hierarchy is only known after
CHECK time of the main program this is where it will be reported.

This brings up the question of how to resolve the error from the top
of the hierarchy. The simplest form is some renaming. For a standard
type like Complex the names .im and .re might be reserved. IOW, it's
documented that a 'use Complex' might result in method conflicts
because it adds these names from the top. Then the standard type can
be implemented in a module.

Well, if the conflict occurs in a class that is under the authority
of the programmer she might resolve it there of course. But that
shouldn't be mandatory.


Regards, TSa.
--