overriding invoke from PIR

Austin Hastings Austin_Hastings at Yahoo.com
Wed Nov 11 21:33:35 UTC 2009

Andrew Whitworth wrote:
> That's a good point, Austin, but I think it does a lot to illustrate
> just how complicated and confusing the keyword "self" is in PIR.
> Looking at three examples here, where bar is an Object, and foo is a
> custom method PMC:
> 1) foo("x")
> 2) bar.foo("x")
> 3) foo.invoke("x")
> My suggestion is this: First, we get rid of the keyword "self". It's
> too limiting and confused. Instead, I suggest we do this:
> .param pmc myself :invocant
> .param pmc mysub :current_sub
> Now, for the three examples:
> 1) myself = null, mysub = foo
> 2) myself = bar, mysub = foo
> 3) myself = foo, mysub = invoke
This is just wrong. In every single case, according to your scenario, 
foo is a custom method PMC. And therefore in every single case the 
dispatch of interest will be to the foo.invoke method. So mysub had 
better be C< invoke >, rather than C< foo >. (Of course, the foo.invoke 
may transfer the execution someplace else, in which case all bets are 
off. But I don't think that's what we're talking about, is it?)

In cases where C< .invoke > is not overridden, the C< mysub > has very 
little value that I can see, and in cases where C< .invoke > *is* 
overridden, it provides no information.

I don't have any problem understanding the current semantics of C< self 
 >. If vtable invoke is overridden, I maintain that C< self > should 
refer to the invocant of the C< .invoke() >, which is going to be C< foo 
 >, rather than C< bar >.

If you're going to campaign for the C< :invocant > keyword, and I 
understand there is a TT on this issue (plus some unsatisfied promises 
in the PDDs, I think), I don't think this area is where the problems 
will occur. A better question is the relationship between C< :invocant > 
and the C< :method > attribute.

Pmichaud has been campaigning to get methods out of the namespace. Which 
means that C< :method > should be doing ":anon + predefine(self)". If we 
eliminate the C< self > builtin, then AFAICT, C< :method > becomes an 
alias for C< :anon >.

Since that's where I think a lot more use cases are going to happen, can 
we get any C< :invocant >-inspired changes to C< :method > hammered out 


> In these three cases, the values for myself and mysub have consistent
> semantic meanings, and yet we're able to identify and handle all three
> of these causes unambiguously. Because all three cases are
> semantically distinct, and we shouldn't be shoehorning all instances
> of invocation to use a single pattern.
> I say we deprecate the "self" keyword in PIR, or we agree that it
> should have a consistent semantic meaning as an alias for :invocant.
> Anything else is far too confusing.
> --Andrew Whitworth

More information about the parrot-dev mailing list