Hi Stevan,

I am posting this on the MOP repo - lack of a better place for these kind of general topics.

It started out as an enhancement request for the roles pragma and ended up becoming a general note about the MOP and the slots roles pragmas, as well as the @DOES and %HAS conventions (suggesting 2 similar symmetrical conventions along the way: @HAS and %DOES).

It's quite loooong. And it might contain a high amount of gibberish. My apologies if that's the case.

The @DOES and %HAS conventions ..

Having a mechanism through which a package (role, class, whatever) can simply state the roles it wishes to do, without bothering with the details of how they are composed, is very interesting.

And one way of achieving that is to stuff those wishes in an array (like @DOES), in a way akin to @ISA.

Same goes for the ability to declare a slot by just putting some stuff in a package variable %HAS (or @HAS, see below).

I think this an excellent idea... And I hope to convince you to stop seeing these as just "surface features" of the new MOP and the slots / roles pragmas, as mentioned in 4.

If well specified/documented, those package variables have got the potential to become a glue/wormhole between the living quarters of Flintstones and the Jettsons and anything in between...

-- as simple conventions that can be followed by any current or future MOP / role-composer, including the popular Role::Tiny, the Cor project, and perhaps even the Mo* family at some point...

That sort of thing is well served being "low-tech"... And that's the beauty!

The fact that roles are not currently implemented in core is mostly irrelevant, I believe. So is the "hijacking" of the package symbols --which can be a problem, yes... but not in any way different than what it would be if it were done by core...

There do appear to be a few hurdles on that pathway, though...

The case of @ISA

• 1. The good old @ISA is normally pure data;
• 2. It's where a package/class declares its immediate ascendants (immediate == "local", in MOP parlance), which conceptually correspond to what a class wishes to descend from, nothing more.
• 3. @ISA doesn't itself contain any "dirty state" of the inheritance operation or method dispatch. Caching and other dirt occurs elsewhere.
• 4. There are a gzillian ways to populate @ISA... use parent being the preferred one these days... Normally, it doesn't matter who populated it or how, as long as it is there when it is needed (method dispatch).
• 5. The code that populates @ISA is not typically the code that implements any form of inheritance or method dispatch. The base pragma partially violated this (by entangling itself with %fields and pseudo-hashes). Remember what happened later?

What troubles me with roles, slots and the MOP

In a nutshell, I think the roles and slots pragmas are doing too much and the MOP commits a sin by reading from and writing to the same place, namely %HAS :-)

• 1. The roles pragma does too much because it combines (and tightly couples) the declaration and composition of roles. This is somewhat akin to what plagued the base pragma over time.
• 2. A similar situation applies to the slots pragma, which goes beyond simply stuffing the caller's wishes somewhere, but actually schedules slot inheritance.

• 3. Also, both the roles slots pragmas (well, actually the MOP) commit a sin by stuffing the dirty state (i.e. one of the outcomes) of role composition within the %HAS hash (which also serves as their INPUT)

     I am not sure if there is an existing module that commits an equivalent "sin" for @ISA. The analogy would be something like mro module rewriting @ISA at UNITCHECK time and stuffing the equivalent of get_linear_isa() in there...

Suggested evolution

Here's an alternative way of dealing with the above (which you might have already considered and ditched; if so, I would really like to hear the reasoning), which entails hijacking 4 package variables (instead of 2) though:

• wishes in @HAS ==> merged to %HAS (during successfull composition)
• wishes in @DOES ==> merged to %DOES (during successfull composition)

This may sound complex, but I think it actually results in something simpler, and does away with some of the circularities, both conceptually and implementation-wise. Just bare with me, please.

• The array variables (@HAS and @DOES) would be where "local" wishes are recorded by mere mortals (or thru dumbed down versions of the slots and roles pragmas, as described below), meaning ==> @DOES would keep its current semantics.

• The hash variables (%HAS and %DOES) would be where the related claims are placed, typically merged in via role composition (but not necessarily), meaning ==> %HAS would keep its current semantics.

  The suggested %DOES convention (where role claims would be placed) is more of a nice-to-have, but its presence provides a symmetrical way to present things, also absorbing the gist of Class::DOES along the way.

• The slots and roles pragmas become even simpler than they already are, they would just be stuffing things in @HAS / @DOES respectively (similar to what the parents pragma does to @ISA), without doing/scheduling any composition.

• A conforming composer (like MOP and possibly Role::Tiny and Object::Pad) would just look at @HAS and @DOES in order to gather the relevant requests, then do their thing, and then merge the resulting successfull claims in %HAS and %DOES.

Any other conforming composer (like Role::Tiny, or Object::Pad, if they wish to conform) would also be able to merge things in %HAS or %DOES. This could also include mere mortals (at their own risk)

• The DOES() method becomes trivial (wherever it is implemented): it would only have to look at %DOES and just deal with the @ISA interplay. It would need no services from the MOP (except perhaps a utility function for gentle stash access, currently in MOP::Internal::Util).

And the whole thing is pretty much compatible with the current state of affairs (in terms of API) and requires minimal to no changes to UNIVERSAL::Object (the more stable sister of the bunch), depending on the way you look at it.

It comes with a small nuisance though:

• Participating classes and roles (those adding slots or wishing to do other roles) would need to use an additional module, which I nicknamed Composer below (just made up the name, it's probably not the best).

  Composer, also quite a brief, is where role/slot composition would be scheduled (instead of from within the slots and roles pragmas). If/when the MOP makes it to core it may become a no-op.

What's the point ?

What do we gain from this nonsense?

In terms of direct functionality gains: not much -- except for a future possibility to reconstruct slot definition order via @HAS, which may become handy at one point.

The main advantages come from a clear separation of concepts and concerns, and a potential for interop going forward.

In this paradigm:

• The @HAS and @DOES conventions can be independently specified/documented, focusing only on semantics. They become true declarations of "local" wishes / requests. This is very similar to the case of @ISA.

• The dumbed down versions of slots and roles pragmas can be used anywhere without any implied entanglement with a any given implementation, just like the parentpragma. They also become the perfect places to document and maintain the @HAS and @DOES conventions. You also get quasi immediate and solid behavioral stability for the slots and roles pragmas. They become so dumb and boring so as to deserve v1.0 on a fast-track. -- otherwise, people would possibly sue them in the future for name-squatting :-)

• The %HAS and %DOES variables are where things are reported / claimed (as opposed to simply being requested). For example, in addition to "local" slots coming from @HAS, the inherited/composed slots also find their way into %HAS. Likewise, the %DOES hash would contain all the roles done by a given package (including those composed through roles that do other roles), but not necessarily those done by its ancestors.

• With these small adjustments, it becomes very easy to swap composers at will (and experiment with new ones) without reinventing too many wheels and new conventions.

• The MOP remains to be a passive light-weight toolbox/library with no state of its own (like today).

• A Composer is an active thingy: it takes initiative (if used). It uses a MOP to do its thing. Going forward, there may be different implementations for each.

• The standard Composer (or alternate composers) do not really need to expose much of an API distinct from what is described. Almost no one really needs to call upon their specialized methods:

• They get their INPUT from known places (@HAS and @DOES) with documented semantics.
• They do their thing when they see fit (thanks to your phase-scheduling code)
• After doing their thing, they just spit out their OUTPUT (report) to other known/documented places (%HAS and %DOES)

This should also make it easier to include this stuff into the core. Just one hook on UNITCHECK.

What do we lose?

Possibly, some run-time meta-dynamism?... Not sure. In any case, if we want that, we need to make sure that a successful compose_roles() operation can be repeated without issues .

CODE

Enough chatter. Here's some CODE, which should be much clearer than the long description above. (just to show intent. didn't even check if these compile)

Example usage

package Point;
use Composer;                       # May become a no-op if MOP makes it in core. 
use parent qw/UNIVERSAL::Object/;
use roles  qw(Geometric);
use slots (
    x => sub {0}, 
    y => sub {0}
); 

package Point3D;
use Composer::Some::Alternative;   # Allow alternative composers and experimentation.
use parent -norequire, qw/Point/; 
use slots (
    z => sub {0}, 
);

The slots pragma

The slots pragma becomes, in essence:

package slots;

sub import {
    shift;
    my $pkg   = caller(0);
    {
        no strict 'refs';
        push @{"$pkg\::HAS"}, @_;
    }
}

The roles pragma

The roles pragma itself would become pure, void of any knowledge of how/when or even by whom a role will eventually get composed.

In essence:

package roles;
use Module::Runtime ();

sub import {
    shift;
    my $pkg   = caller(0);
    Module::Runtime::use_package_optimistically( $_ ) for @_;
    {
        no strict 'refs';
        push @{"$pkg\::DOES"}, @_;

    }
}

The DOES() method

The default DOES() method becomes (wherever it is implemented) :

sub DOES {
    my ($self, $role) = @_;
    # get the class ...
    my $class = ref $self || $self;
    # if we inherit from this, we are good ...
    return 1 if $class->isa( $role );

    # The suggested %DOES convention.
    # This is not absolutely necessary, but just makes things
    # simpler and potentially interopable between different MOPs.
    # - TABULON
    { 
        no strict 'refs';
        require mro;
        for my $pkg ( $class, mro::get_linear_isa() ) {
            # Not exactly sure about the interpretation of a false value for a role.
            # The below interprets it as an explicit claim for NOT doing a ROLE.
            # FIXME::may need to access more gently or just go thru the MOP.
            return ${"$pkg\::DOES"}{ $role } // 1 if exists ${"$pkg\::DOES"}{ $role };  
        }
    }
    return 0;
}

Note that, in terms of behavior, the above %DOES convention is almost identical and should be interoperable with Class::DOES. The only difference is the interpretation of falsy values in the %DOES hash:

• What I suggest above provides an easy way for a thingy to claim that it does NOT do a given role (maybe useful for debugging or what not). Not sure about this, though.

The Composer module

This is where things are actively tied together, but it's also dead simple (thanks to the MOP doing all the hard work).

package Composer;
use MOP ();

sub import {
    shift;
    my $pkg   = caller(0);

    MOP::Util::defer_until_UNITCHECK(sub {
        my $meta  = MOP::Util::get_meta( $pkg );
        MOP::Util::inherit_slots( $meta );  # would we still need this line ?
        MOP::Util::compose_roles( $meta );
    });
}
 

OPEN QUESTIONS / ISSUES

Accept OptList as arguments for slots and roles pragmas ?

The slots pragma already accepts key-value pairs. It might be interesting to consider accepting an OptList as well (in the Data::OptList sense, but not necessarily depending on it).

A similar consideration applies to the roles pragma which currently accepts a flat list of role names. An upgrade to OptList looks like a natural fit there, once we start defining (or better yet, stealing) a sub-syntax for certain options that may be needed for resolving conflicts during role composition (exclusion, renaming, aliasing, ...).

I am not that sure about the form of the actual contents of @HAS and @DOES, though...

Guard against multiple COMPOSERS stepping on each others toes

Basically we would want to avoid alternate composers from stepping on each others toes, like in the case below :

use Composer;
use Composer::Other;
use slots ...;
use roles ...;

It might be possible to tackle this by having a Composer implementation mark its name within yet another package hash.... or export a subroutine or something... Need to think this through.

In any case, it smells like a stairway to... METACLASS()... :-)

...

There are some other open questions and points worth raising. But this post is already veeeery long...