overriding invoke from PIR

Austin Hastings Austin_Hastings at Yahoo.com
Wed Nov 11 19:19:05 UTC 2009


A method is, in this case, an object that is performing one of its 
possibly myriad behaviors.

That is, if I say

    my $bank_account := CheckingAccount.new('100.00');

it is pretty clear what is happening. I think that the same is true for

    my $method := Method.new(...);
    my $call_signature := CallSignature.new(...);

In this case, the $method is the object, and so should be self. The 
hypothetical invocant of the method should be encapsulated, along with 
all the other arguments, inside the call signature.

Self, IMO, refers to the method, while $call_signature[0], or 
$call_signature<self>, or however you want to access it, refers to the 
object upon which the method is operating.

The point here is that by making the override, we have "gone meta" and 
so the method is no longer just a sub, but now is a first-class object. 
Anytime you're inside the namespace of that object, self refers to the 


Andrew Whitworth wrote:
> 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
> answering.
> 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:
> foo()
> here, we invoke foo directly. Second:
> bar.foo()
> 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
> sub:
> .sub baz
> .param pmc myself :self
> .param pmc currsub :current_sub
> ...
> .end
> 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
> specified), etc
> ...And drawbacks:
> 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.
> --Andrew Whitworth
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev

More information about the parrot-dev mailing list