Re: Objects, finally (try 1)

[Dan Sugalski]

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.

The bound method call thing we can do as a curried function, so I'm not that concerned about it in general, but it does definitely imply that we need to build in currying support to the core rather than leaving it to the compilers to do, though there's no reason that the functionality can't be left to the python opcode backwards-compatibility set and more explicit logic built into the python front end, but...

Hrm. I appreciate the heads up here.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk