overriding invoke from PIR

kjstol parrotcode at gmail.com
Wed Nov 11 23:58:16 UTC 2009

I just have one issue with using flags like :self and :current_sub to
indicate what a particular .param would be, and that's the order.
Using :flags like these implies that you could write:

.sub foo :method
 .param pmc x
 .param pmc y
 .param pmc a :self
 .param int b
 .param string c :optional
 .param int hasc :opt_flag
 .param pmc :current_sub

In other words: the position of the :self and :current_sub parameters
seems to be  random. Of course, the reply on this would be: don't
allow that. Just allow :self and :current_sub on the first parameters.
You could do that, implement this kind of check, but it just feels
very hacky to me.

Just a note of the language lawyer here :-)


On Wed, Nov 11, 2009 at 9:33 PM, Austin Hastings
<Austin_Hastings at yahoo.com> wrote:
> 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 first?
> =Austin
>> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev

More information about the parrot-dev mailing list