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. /Erik -- Erik Bågfors | [EMAIL PROTECTED] Supporter of free software | GSM +46 733 279 273 fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
