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