On Thu, Apr 10, 2008 at 6:59 PM, Jonathan Worthington <[EMAIL PROTECTED]> wrote: > Hi, > > We have a couple of bits of OO stuff missing in Parrot. > > The callmethodsupercc op isn't implemented. I'm thinking for this we need a > variant of find_method, which does the required skipping over the current > class? > > We'll also need to work out how to do callmethodnextcc too, which is > another find_method variant, I guess. It occurs to me that if we're doing a > next method style thing, then we know what the last method was, and we can > pass that as a "resume from this point" style thing, and if possible that > can be optimized somehow later to do something better than the obvious going > through the lookup process until we find the current method and then > returning the one we find after that. > > Even with super implemented, this doesn't help me with a more immediate > issue. I need to take a PMC, subclass it with a high level class, then > override one of the v-table methods in PIR. All this I can do fine. But what > I can't see how to do with what we currently have (neither spec'd nor > implemented), is to invoke the super of the v-table method. For example, you > might want to override assign_pmc to do some check on the value, and then > call the original v-table method in the PMC we inherited from to actually > stash the value being assigned somewhere. What should this look like at a > PIR level? In fact, this last issue is the main one I'm blocking on at the > moment.
I can't speak for *should*, but Tcl is doing this now: languages/tcl/src/class/tclconst.pir subclasses String, then overrides set_string_native. Once we're done with our string manipulation, we then invoke string's copy of the vtable to actually store the desired value: # Finally, delegate to our parent's set_string $P0 = getattribute self, ['String'], 'proxy' $P0 = value > Thanks, > > Jonathan > > > -- Will "Coke" Coleda
