Andrew Whitworth wrote:
On Sat, Feb 14, 2009 at 4:21 PM, Allison Randal <[email protected]> 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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
