At 8:42 AM +0100 1/23/03, Erik Bågfors wrote:
On Wed, 2003-01-22 at 19:46, Christopher Armstrong wrote:
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'? I don't
really know anything about the vtable stuff in Parrot, but is it
possible to totally delegate the lookup/calling of "foo" to a function
that's bound somehow to P1? Or does the "foo" entry have to exist in
the vtable already? Sorry for the naive question :-) Oh, and if you
just want to point me at a source file, I guess I can try reading it
:-) Python basically requires that each step in the process be
overridable. (1. look up attribute 2. call attribute, at least in
`callmethod's case).
Ruby needs to call the missing_method method (if I remember correctly).
So if "foo" doesn't exist, it would be good to be able to override
callmethods behavior and make it call missing_method.
This'll be core functionality if languages want to use it. Perl has a
similar function, AUTOLOAD, that gets called if you make a
nonexistent method call. It sounds like we need generic pre and post
method call handler functionality as well, which should be
interesting to design.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
