On Mon, Feb 2, 2009 at 9:16 PM, Andrew Whitworth <[email protected]>wrote:
> Current behavior of IMCC is to allow the "self" keyword in ordinary > subroutines. If "self" is present it's treated like a magical PMC > variable that is given the value of the first passed parameter. If no > parameters are passed, you get the cryptic error about too few > parameters being passed, when it appears that no parameters have been > defined. So this code: > > .sub 'mySub' > $P1 = self > .return > .end > > is valid PIR, even though calling it will likely Do The Wrong Thing. > Instead of getting a helpful error about using "self" where it > probably shouldn't be used, you get an error about how 0 params are > passed but one was expected. This is weird because there are no .param > values declared here, so it seems 0 params were passed and 0 params > were expected. > > Of course we can't get rid of this, because subroutines can be > declared as subs but registered as methods on the class object later. I find this fact, that normal subs can later be added as methods (so they're 'upgraded' to methods), enough reason to +1 on your proposal. Otherwise, I'd have doubts, but I think things become very very tricky, if not impossible, for a PIR compiler to add 'self' as a parameter only if :vtable/:method is set, because you can't know whether a sub will become a :method later anyway (through runtime add_method() ). So, +1 from me. kjs > > We also can't require that every sub that uses "self" be labeled as > ":method", because it's useful in ":vtable" subs as well, and maybe in > other places too that I haven't thought of. > > We also have the problem from TT #103, where "self" can't be used from > inside overridden "invoke" vtable subs for a number of reasons. When > we call a line of code like this: > > $P0() > > IMCC doesn't know at compile time what type of PMC $P0 is, so it can't > know before hand that it's an Object, and can't know that there's > going to be an overridden invoke sub somewhere that's expecting a > "self". IMCC doesn't pass it, and then when "invoke" looks for it you > get the error "0 params passed, (1) param expected". We've mentioned > in various places ways to get around this: > > $P0.$P0() > > or > > $P0($P0) > > Neither of which are particularly appealing to me. > > > My proposal is this: All subs get the "self" keyword, whether they > want it or not. "self" in all subs point to the object that was being > invoked. In an ordinary subroutine, "self" will refer to the Sub PMC > itself. Ignore it if you don't want it, and nothing really changes > from how things are treated now. Objects, when invoked, will have this > "self" if they want it, which they probably always do. This also is > going to help us a lot internally, where we can unify the functions > for calling methods and functions for calling non-method subs. We > simplify a few things in IMCC too, although we do pay because an extra > parameter is being passed in many cases where it's not needed. As part > of this, I may also like to change VTABLE_invoke to take 4 parameters > instead of 3 (adding an optional invocant PMC, if it's different from > the sub object being invoked). > > What do people think of this proposal? Any immediate problems come to > mind that would make this a Bad Idea? > > --Andrew Whitworth > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
