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. --