Proposal about the "self" keyword

[Allison Randal]

Andrew Whitworth wrote:
> On Sat, Feb 14, 2009 at 4:21 PM, Allison Randal <allison at parrot.org> wrote:
> 
> Well, here's how I was thinking about it. We want the behavior between
> various PMC types to be consistent. If we call
> 
> $P0()
> 
> Then "self" in the invoked routine should refer to $P0 here,
> regardless of whether $P0 is a Sub, or a user-defined Object. When we
> invoke something, "self" should be the object that is getting invoked
> (or the object that is getting invoked upon).

A keyword that gives you two completely different answers depending on 
how the code object was invoked ('self.$P1()' vs 'self()') is not 
consistent. It's problematic for code objects that can be invoked as 
both subs and methods. And, once there is a way to access the code 
object currently executing, I can guarantee people will want to use it 
in methods as well as sub (but won't be able to if it's accessed through 
'self').

> 
>> Personally, I'd like to eliminate the automatic "self" keyword entirely, and
>> replace it with an explicit parameter declaration:
>>
>> .param pmc self :invocant
> 
> That's a nice thing, but still doesn't resolve the problem that we
> can't reliably know when or even if to pass "self" to invoked
> subroutines. When we call "$P0()", we can't know the type of a PMC at
> compile time. It could be a Sub, or an NCI, or an HLL mapped
> subroutine type that's going to defer to an invoke vtable override in
> PIR. We are going to run into lots of problems where IMCC or PIRC
> don't the code to pass "self" in cases when it really needs to be
> passed, unless we change things to just always pass it (or find some
> other way to make it available outside normal parameter passing).

Ah, well, we already have a solution for knowing whether optional 
parameters have been passed:

   .param pmc self     :invocant :optional
   .param int got_self :opt_flag

(And if 'self' isn't marked as optional, then the .sub can *only* be 
called as a method.)

> As a side note, creating and using a "getself" opcode would actually
> be a net win because we replace the current get_param/set_param pair
> with a single "self = getself" op instead. Just a thought.

I can see adding some sort of introspective ability to access the code 
object for the current sub/method that's executing. It would be useful 
in exception handlers too, to access the code object of the handler 
that's currently executing. But, it's not 'getself' because you're 
getting the code object, not the invocant. Call it something like 
'get_current_sub'.

Allison