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.



Reply via email to