Method startup operations

[leonerd]

Where should the code that runs at the start of every method actually live?

The tasks it has to perform:

• Check that $_[0] is an reference to a compatible object instance
• Assign that reference into the $self lexical
• Shift it from the arguments list before signature processing happens

In Object::Pad this is performed by a new (custom) op called methstart.

[leonerd]

A core implementation might use a new op for this as well, or it might roll some (or all) of the behaviour into pp_entersub.

At least initially it's probably best to just go with a new op type. That means no existing code pays any performance penalty for these new operations. It might eventually make sense to fold it into the more general argument setup code that entersub will end up doing, or whatever else happens with the "no-snails" idea.

[yuki-kimoto]

Check that $_[0] is an reference to a compatible object instance

What does the word "compatible" mean?

The following?

$foo isa Foo

I afraid the addition of performance cost.

[leonerd]

Current Implementation (2022-08-17)

The first op within a method CV's optree is an OP_METHSTART. If the method is using signatures, this happens even before the OP_ARGCHECK. In addition, it is spliced in before the first OP_NEXTSTATE, so that any croak() calls will appear to come from the caller's location, as PL_curcop still points there.

The pp_methstart function has a number of responsibilities:

1. Checks that the first argument (the $self) is a valid object reference in the right class; it will croak() if not.
2. Shifts this self reference off the arguments array (therefore, a signature will not see it) and stores it into the lexical pad at padix 1.
3. Checks that the object instance has the right number of fields (this is mostly a debugging / safety check. It ought not be possible for regular perl code to ever create an object instance with the wrong number of fields for its class)
4. Performs the "field binding" operations.

Field Bindings

This final operation is the core of what makes field accesses work within methods. Every field of a class is stored in the pad of its surrounding scope, and is this visible for lexical capture by method bodies. When the method body is created, a note is taken of every field actually captured by the method, and which pad index it is captured into. This list of pairs of (pad index, field index) is then stored in the UNOP_AUX list of the OP_METHSTART op. At runtime when the method starts up, this list of pairs is used to create lexical aliases to those instance fields, so that during execution of the method body any SV access into the pad is really accessing the object fields of the instance that invoked it.

Each association is saved onto the savestack so that on stack unwind the pointers can be removed again.

Because fields are stored as real SV pointers in the pad of a method, any nested closures can continue to capture them by the usual operations. Thus, code such as the following will work as expected:

class Counter {
  field $count;
  method make_incr { return sub { $count++ }; }
}

When the make_incr method is called, its body contains an OP_ANONCODE op responsible for cloning a new CV to store the closure. That closure captures the current SV stored in the pad for the $count lexical, which happens to be the SV storing the count for the particular instance that invoked it. Thus, the returned closure is still bound to the correct field of the correct instance even after the actual method body has returned.