Proposal about the "self" keyword

[Andrew Whitworth]

On Sat, Feb 14, 2009 at 4:21 PM, Allison Randal <allison at parrot.org> wrote:
> The problem is that this introduces confusion between the invocant and the
> invoked code object. "self" should always and only refer to the invocant,
> and never refer to the invoked code object. And, "self" should never exist
> if the object wasn't invoked as a method. (Yes, it should give a more
> helpful error message.)

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).

> 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).

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.

--Andrew Whitworth