Method representation

[leonerd]

How should "methods" be represented?

A method is primarily still a function, so a CV still seems fine. But it does require a few additional bits of data:

• The originating role for methods composed from roles
• Additional flags - {is-common}

[yuki-kimoto]

I think the flag whether the method is instance method or class method is needed.

sub ($class, $arg) { }

[Ovid]

Originating role is probably fine, but just as food for thought, the original traits specification for Smalltalk made it clear that if two roles present methods with identical signatures, there is no conflict if the bytecode representation is the same. Thus, you could have two or more roles presenting the same method. If we were using something like this for automatic refactoring tools, we'd want to know all of the methods that presented an identical method.

We probably don't want to inspect the bytecode per method, but I thought I'd mention that in case I'm wrong. However, by ignoring identical bytecode, we have to be explicit in method exclusion. That means "originating role" will still work, but I know there are those who are strongly against aliasing and excluding. (Personally, I'd also add "rename" which is is a combination of "alias" and "exclude")

[leonerd]

Methods now have the CVf_IsMETHOD flag. As yet there's no extra storage for extra details though. This will need some further thought.

[leonerd]

Current Implementation (2022-08-17)

(This issue is about the static representation of a method within a class. For more details on the runtime behaviour of how a method body will run, see also #8)

A method is a CV, with additionally the CvIsMETHOD() test macro returning true. (This macro should not be confused with the one that was previously called CvMETHOD(), and has subsequently been renamed CvNOWARN_AMBIGUOUS() because of this fact).

Currently, a method CV does not store any additional information; nor is its existence tracked by any additional data in its class stash, beyond the regular operation of GVs in the stash as would be the case for a regular sub in a regular package.

API

A method CV is created by beginning a CV parse operation using the usual start_subparse() function, after which the following function must be called immediately, before any other parsing commences:

void class_prepare_method_parse(CV *cv);

This function sets up the $self lexical and otherwise generally arranges that parsing will work. Once the method body optree has been created but before calling newATTRSUB() or similar, the following function must be called on the optree body:

OP *class_wrap_method_body(OP *o);

The result of that can then be passed into newATTRSUB() to construct the actual method CV.

This API shape is a rather delicate balance. It is likely to change before code merge, by folding more parts of the operation into start_subparse() and newATTRSUB() automatically. In particular, it may be the case that either start_subparse() will change in API shape to allow the caller to say "this is for a method", or a new API function start_methodparse() will be added to combine them.