Class representation

[leonerd]

How should classes actually be represented?

Since a "class" is still a "package", I feel the way forward is to still back them by an HV storing the stash. It then requires a place to store all the extra data about that class.

Inspired by Object::Pad, the sorts of data that would be required might include

• A set of flags {sealed, role-is-invokable, strict-params, has-adjustparams, has-superclass}
• start fieldindex, next fieldindex
• List of fields
• List of methods
• Map of parameters
• List of required method names
• Lists of BUILD, ADJUST and ADJUSTPARAMS blocks

Additionally, for true classes:

• The superclass
• List of applied roles

And for roles when we get there:

• List of superroles

In addition to those fields of actual data, the Object::Pad implementation also stored quite a bit more derived information from those, partly for performance reasons.

[leonerd]

In practice in perl every stash already has the HvAUX structure attached. This structure has a U32 flags field, of which currently only two flags are defined. We can easily define some more.

In particular we could define one more to say "this stash is a class", and then add more fields to the struct xpvhv_aux structure to store this extra data. Or perhaps if we're cautious of using too much memory for the majority of stashes that aren't classes, either give it one more pointer to the extra class data, or just optionally use a different aux structure with additional fields at the end of it. Either way, the flag can indicate its validity.

[yuki-kimoto]

I think the list of class variables (package variables) is needed.

[leonerd]

I don't see why. Regular package are already members of the stash via the usual way (i.e. globs). There's no need to handle them any differently here.

[leonerd]

Current Implementation (2022-08-17)

A class is a stash, with additionally the HvSTASH_IS_CLASS() test macro returning true on that stash.

In this case, the HvAUX structure will have some additional fields that are valid:

    /* The following fields are only valid if we have the flag HvAUXf_IS_CLASS */
    AV          *xhv_class_adjust_blocks;      /* CVs containing the ADJUST blocks */
    PADNAMELIST *xhv_class_fields;             /* PADNAMEs with PadnameIsFIELD() */
    PADOFFSET    xhv_class_next_fieldix;

These fields:

• xhv_class_adjust_blocks - a regular AV whose elements are direct CVs (i.e. not indirected via RVs). each one implements one ADJUST block of this class. They are stored in declaration (and therefore execution) order.
• xhv_class_fields - a PADNAMELIST, all of whose PADNAMEs are the fields of this class. They are stored in declaration (and hence initialisation) order. This is a PADNAMELIST, not an AV, because PADNAMEs themselves are not SVs, so an AV would not be appropriate storage for them.
• xhv_class_next_fieldix - used during compilation to know what is the fieldix for the next field to be added. Currently this is equal to the length of the class_fields padnamelist, but it will be useful to keep it distinct when the ability to derive subclasses is added.

API

A regular package stash is converted into a class stash by calling:

void class_setup_stash(HV *stash);

Once parsing is complete (at the end of its inline block, or at the end of the containing scope for unit classes), there is another function to call:

void class_seal_stash(HV *stash);

(Currently this function does nothing, but from experience on Object::Pad it is highly likely that various activities will need to be performed in here, so this is reserved for that)

Fields and ADJUST blocks are added by:

void class_add_field(PADNAME *pn);
void class_add_ADJUST(CV *cv);

These two API functions implicitly operate on the class stash in PL_curstash (hence, at compiletime), though it is likely this API shape will be changed to pass that in as an additional parameter.