overriding invoke from PIR
wknight8111 at gmail.com
Wed Nov 11 19:01:19 UTC 2009
NotFound posted a very interesting patch to TT #1262 to enable us to
start overriding invoke VTABLE from PIR. it's incomplete at the
moment, because there is a bit of a syntactical question that needs
To illustrate, consider two objects: foo and bar. Bar is an ordinary
Object, while foo is a custom Sub-like PMC type with invoke. First:
here, we invoke foo directly. Second:
Now we're invoking foo again, but now bar is the invocant.
In PIR, the "self" keyword refers to the invocant. So in the second
example I think we would all agree that bar is the invocant and so in
the invoke override "self" should refer to bar. So how then, inside
the invoke, do we get a reference to foo? If you look in
compilers/imcc/pcc.c:unshift_self(), the handling of the invocant is
relatively lousy and O(n).
I would like to propose a change. I propose that "self" no longer be a
magic keyword. Instead, I suggest that we should use new .param types
to get references to the current invocant and the currently executing
.param pmc myself :self
.param pmc currsub :current_sub
So in the case of "foo()", myself == currsub == foo (or, myself ==
null, currsub == foo). In the case of "bar.foo()" myself == bar,
currsub == foo.
This gives us a few benefits:
1) We'll be able to start overriding VTABLE_invoke in a meaningful way
2) We'll be able to detect whether a Sub was invoked as a
standalone-sub or as a method
3) This should get the :invocant thing working, which has been
requested for some time (whether we call it :invocant or :self or
whatever is a matter of some bikeshedding).
4) I think we can implement these flags without decreasing PCC performance
5) We should be able to do this without deprecating or chnging the
behavior of the "self" keyword as it is now (though we could make it
lazy, so "self" only exists if an ":invocant" has not been explicitly
1) In every other VTABLE, "self" will refer to foo. But in invoke
"self" will be something else and :current_sub will be foo.
2) I'm going to have to get within 100 feet of IMCC.
So I would like to get some feedback from devs, especially HLL devs
about whether this would be a good change.
More information about the parrot-dev