Dan Sugalski <[EMAIL PROTECTED]> writes: > At 3:06 PM -0500 1/15/03, 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. :) >> >>> I'll add "define method dispatch more" to the list o' stuff for the >>> next edit of the proposal. >> >>I'll help you along by offering this explanation of how instance >>methods work in Python. (sorry if you're already familiar with this >>stuff, but it's in my best interest to make sure you are ;-)) >> >>When you say something like `o.foo()', it translates into these steps: >> >> 1) LOAD_NAME 'o' >> 2) LOAD_ATTR 'bar' >> 3) CALL_FUNCTION >> >>#2 has extra magic. What I mean is, when you LOAD_ATTR a function from >>a *class*, you just get back a plain old `unbound method'. When you >>LOAD_ATTR from an *instance*, and (after failing to find an instance >>attribute) the attribute is found on its class, you get a `bound >>method', which basically means that Python has "curried" that method >>so the first argument is automatically passed -- that first argument >>is the instance which you LOAD_ATTRd from. This is why you see all >>those python methods with the first argument being `self', and rarely >>see code which explicitly passes that first argument. >> >>Now, like I said, this magic is done in LOAD_ATTR, not CALL_FUNCTION, >>so you can take that bound method object and do whatever you want with >>it before calling it. >> >>Here's an interesting code snippet which also demonstrates the fact >>that methods are just attributes. > > Hrm, interesting. Single symbol table for methods and attributes, > though that's not too surprising all things considered. That may make > interoperability interesting, but I was already expecting that to some > extent.
Isn't that, essentially what Perl 6 will have too? It's just that the sigil will be taken to be part of the symbol. Thus a method's symbol will be &method (method?). Presumably one would first check with the object for a matching symbol and then search up the class tree until something comes up (which could then be cached back on the object, though that would require some smarts on the object's binding to the method so that Parrot could distinguish between cached methods and 'custom' methods (hopefully the binding would also contain information about where a cached method was found so that SUPER:: type dispatch could be done dynamically instead of using the current hack based on the package in which the C<< $self->SUPER::method() >> call was compiled (what me? On a hobby horse? Never!))) Hmm... was that a paragraph or an S-expression? -- Piers
