Leopold Toetsch wrote:
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):
    ...

In Python, this is statically determinable. If that sequence is directly nested inside a class, it is a method, otherwise it is a function.


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.

Less shifting will be required if the object is passed in P2.

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

But this translates into two VTABLE calls. find_method and invoke. find_method needs to return a bound method.


A find_method_and_invoke VTABLE entry (or more simply call_method) would not need to return the intermediary bound method.

... Removing the shifting of PMC arguments will
require the insertion of an interpinfo opcode into each method.

Or fixing argument passsing like above.

Which amounts to "not removing the shifting".

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.

Less shifting will be required if the object is passed in P2.

- Sam Ruby

Reply via email to