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