Larry, On Aug 17, 2005, at 2:53 PM, Larry Wall wrote:
: As for submethods, I see them like this: : : submethod foo () { ... } : : is really .. : : submethod foo () { : next METHOD unless $?SELF ~~ $?CLASS; : } : : At least that is how larry explained to me about a month ago.Can't use ~~ for that, since ~~ implies "does", which is not an exact class match. Probably need next METHOD unless $?SELF.class =:= $?CLASS; or some such.
In the 2.0 version of the metamodel I compare the class object's .id to the instance's class object's .id. Which is (I assume) how =:= would do it under the hood.
Except that BUILDALL/DESTROYALL have to be able to invoke submethods on partial objects whose actual class is not the same as the submethod, so there needs to be some way of forcing $?SELF to consider itself in $?CLASS temporarily for infrastructural purposes. Maybe it's as easy as "temp $obj.class := $tmpclass" in the BUILDALL/DESTROYALL dispatcher. I dunno.
I am not sure if changing classes makes sense here so much as just providing a means for submethod calls to be forced. Currently the metamodels do this by allowing a special parameter in the first argument which is a flag to let the submethod wrapper know if can skip the "next METHOD" branch. It is a bit of a kludge, but it seems to work.
The other option I considered was to make BUILDALL and DESTORYALL special somehow. But I am not sure if this makes any more sense than the kludge described above.
Stevan
Larry
