overriding invoke from PIR
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