Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> WRT functionality: for a call it has to shift up PMC arguments and
>> insert the object as P5, right?
> At the moment, it contains this logic. My plans are to remove the
> shifting and set the object into P2 / INTERP->ctx.current_object.
Dan didn't answer issues WRT argument passing yet. In the current scheme
your plan would be ok - for e.g. a NCI find method. But that doesn't
work fur user methods, especially if there is no indication that a user
function is used as a method in the first place.
def find(s, sub):
...
I've proposed several times that arguments including the object should be
passed from P5 up. The invocant - if any - can still be reachable with
the C<interpinfo> opcode, but it'll be probably used just in calls to SUPER
or next_method or such.
> Notes: at the moment, every Python method call creates a bound object,
> and shifts PMC arguments.
This shouldn't be necessary for "normal" method calls like:
s.f("r")
> ... Removing the shifting of PMC arguments will
> require the insertion of an interpinfo opcode into each method.
Or fixing argument passsing like above.
> If there were a call_method VTABLE entry and if P2 were passed into
> methods, all of this would be unecessary in the majority of cases.
A separate vtable slot doesn't really help. Code that looks like a
function call can actually be a method call (and vv). Separating the
call into two vtables will just duplicate the call sequence. But let's
first convince Dan that all arguments are passed from P5 up, then we'll
see what we have.
> - Sam Ruby
leo
