Christopher Armstrong:
# On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
# > At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
# > >But who knows, maybe it could be made modular enough (i.e., more
# > >interface-oriented?) to allow the best of both worlds --
# I'm far too
# > >novice wrt Parrot to figure out what it'd look like, unfortunately.
# >
# > It'll actually look like what we have now. If you can come up with
# > something more abstract than:
# >
# > callmethod P1, "foo"
# >
# > that delegates the calling of the foo method to the method dispatch
# > vtable entry for the object in P1, well... gimme, I want it. :)
#
# Just curious. Exactly how overridable is that `callmethod'?
Extremely. callmethod maps to a function with a signature something
like
opcode_t * MyPMCClass_callmethod(Parrot_Interp interpreter, PMC*
self, char* name)
Which returns a pointer to the method's entry point, so that we don't
have C-level recursion for every method call. (It's also allowed to
just perform the call itself and return NULL, so you can call into C
efficiently.) The trick is to override MyPMCClass's callmethod to
provide whatever semantics you want to have. We're currently bickering
over whether you can cache pmc->vtable->callmethod's return value or
not, but it looks like either way it should be easily updatable.
# Python basically requires that each step in the process be
# overridable. (1. look up attribute 2. call attribute, at least in
# `callmethod's case).
I'm not sure exactly how this would be implemented but...um...I'm sure
you *could* do it. ;^)
Dan: with the various AUTOLOAD-esque features, can we reasonably expect
to be able to have One True Object PMC?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
