Dan Sugalski wrote:
Hi folks.
Welcome back!
Parrot's got the interesting, and somewhat unfortunate, requirement of having to allow all subroutines behave as methods and all methods behave as subroutines. (This is a perl 5 thing, but we have to make it work) That is, an invokable PMC may be invoked as a method call and passed in an object, or as a plain subroutine and not have an object passed in. As far as perl 5 is concerned the object is the first parameter in the argument list, but for everyone else the object is a very distinct and separate thing.
Python essentially has the same requirement, with a few twists. Specifically, methods come in be static, class, and regular flavors.
But first, a simple example. Strings in python have a "find" method, so and can do the following:
f = "Parrot".find print f("r")
Note that I referenced the method as an attribute, and then called it as a function.
Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like:
$P0 = find_method Parrot_string, "find"
# Elided check for failed lookup and fallback to attribute fetch
$P1 = make_bound_method(Parrot_string, $P0)
$P1("r")Furthermore, the function "remembers" what object it is bound to. This is accomplished by VTABLE_find_method creating a new PyBoundMeth PMC which contains two references, one to the object, and one to the method.
While a good idea, I think it's not the right way to handle this. Binding objects to methods to create invokable subs is going to be something we're going to need for a lot of the languages, so I think we'd be better served providing a general facility to do it rather than leaving it to each individual language designer to do it. Should save some work all around too.
Static methods differ in that the object is not passed.
How is this different from a subroutine, then?
Class methods differ in that the object passed is actually the class of the object in question.
I'm assuming this is different from just a method on the class somehow?
Note: all this is determined by the callee. It is all transparent to the caller.
This is the part I'm not so sure about. It looks like, rather than having two sides (caller and calle) we have three, caller, callee, and the code that fetches the invokable in the first place.
I fully agree that the caller shouldn't know about this stuff, since it may well have been handed the invokable thing as part of a function call or pulled it out of a variable or something.
I don't think the callee should have to know anything special here, though -- it doesn't seem at all unreasonable to have the callee *not* have to do anything special, nor play any magic games. (And I think I'd be a bit peeved if I was writing code which passed in object A as the object being invoked on, but the method decided it wanted to use object B instead) This is especially true in a mixed-language environment when you've got a class with methods written in different languages -- setting up any conventions that'll actually be followed seems like an exercise in futility. :)
That leaves the code that actually fetches the invokable thing in the first place, and that seems like the right place for this to happen. The language the code is written in knows what should happen based on what it gets back when querying the object, so as long as we provide a standard means to do all the binding stuff, we shoul dbe fine.
First, observe that I don't have any control over the exception that is raised when a method is not found (fix: raise the exception within find_method).
Right. There's going to be one generic method-not-found exception -- there really has to be only one, otherwise we're going to run into all sorts of cross-language problems. Exception unification (and, more likely, aliasing) is going to be one of the tricky issues.
My one minor request here is P2 be made available on entry to the invoked method. This would remove some special case logic for me requiring the use of interpinfo. I don't expect any guarantees that this is preserved or restored across sub calls.
The one thing that leaving it in the interpreter structure and not explicitly passing it in gets us is we get notice if its actually extracted and used. Which is going to be fairly common, so I'm not sure what it buys us. I think we'll leave things as-is, but I'm not sure for how much longer.
Not having objects handle their own method dispatch is less clear-cut, but I do have some reasons, so here they are.
Just be aware that in order to preserve Python semantics, find_method will need to return a bound method.
That can't happen. find_method has to return an unbound method, since there are just too many cases where that's what we need. If the method then needs to be bound then the fetching code can do the binding.
This involves creating an object on the heap, garbage collection, and a minor addition to the number of instructions executed on invoke (including a nested C stack).
I think we can make this work without any C stack nesting, if we make binding a primitive operation, which seems the sensible thing to do. fetch_method may well trigger bytecode, and there's nothing to be done about that regardless, but the rest should work out fine.
This could all be avoided if there was a VTABLE_callmethod interface as the code would "know" that the intent was to only use this found method exactly once.
Alas, with continuations there's never a guarantee of 'only once'. :(
*shrug*
Do you plan to choose banana cream again at OSCON 2005?
Not planning on going this year. -- Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
