Hi folks.
Sorry I've been gone so long. Non-p6i stuff's been well past monopolizing my time. Not much of an excuse, I know, but the Real World intrudes at the most inconvenient times. Things are, I hope, easing up a little, though I apologize in advance if I get a little cranky while I get back into things.
Having (very lightly) skimmed the past month of list mail, I'm thinking the best place to start is with the things that've come up about objects and method calls. I want to explain why things are designed the way they are so (hopefully) everyone's on the same page. (And, hopefully, to forestall grumbling when I say things aren't going to change :)
The setup, for those following along at home, is that when we make a method call the object is passed out-of-band (that is, not as part of the regular parameter list), and that objects don't actually handle method dispatch -- we split it into a two step affair where we request an invokable method PMC for a named method from an object, and then invoke it as a separate step.
The easy one first -- why the object is out-of-band, rather than one of the parameters. (Something that I doubt anyone's that worked up over, and I think everyone's OK with things as they stand, but here are the reasons anyway)
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. Regardless invokable things need to know whether they were called as a method or a sub. We *could* set a flag and have them check, then have some convention where the first parameter is an object if the "I'm a method" flag is set, but... yech. Having the object be separate and standalone seems cleaner, while still giving us a way to distinguish method/sub invocation. (You check to see if there's an object)
This does make things a little tricker for the perl 5 code generator, but not that much trickier and, let's face it, we're below the layer where things are easy. This *also* makes building signature checking into parrot a lot simpler (something we should do), since the signature checking stuff doesn't have to deal with possible parameter shifting based on whether we've a sub or method invocation.
Not having objects handle their own method dispatch is less clear-cut, but I do have some reasons, so here they are.
First off, one of the things I'm very much concerned about is C stack usage, both because we don't have all that much we can count on (joys of threads -- we'll be lucky to scrape together 10k some places) and because continuations can't cross C stack level boundaries. We're pretty careful about that one (it's the big reason for the limitation that continuations taken from within vtable functions can't escape).
I realize we can continue to be careful with it, mandating that the invoke_method vtable function behaves the same as the plain invoke does (that is, returning the address to jump to) but that brings up a separate problem -- transfer of control is a relatively heavyweight thing for us. Method and sub calls can potentially cross bytecode and security boundaries. Doing that right requires (potentially) a fair amount of screwing around inside the interpreter, as well as the invokable thing carrying around enough metadata to properly do the transfer. I'd really prefer to limit the number of PMCs that have that amount of intimate knowledge. Since all methods and subs have the appropriate bits attached to them, I'd as soon just use them.
There's also the potential issue of curried methods, where we need to create a new invokable thing and bind some parameters to it. We can certainly do that now with the current scheme so adding an invoke_method to the mix won't get in the way as such, but it does mean we have two near-identical ways of doing the same thing (find_method & invoke, and invoke_method) and since we can't toss the find_method way, it doesn't feel like adding invoke_method to the mix will get us anywhere.
Anyway, there we go. (I fully expect to find that both topics are dead about an hour after this goes out, but there you go :)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
