Re: Shimming The Moose Way

On Thu, 10 Apr 2014, Thalhammer, Jeffrey Ryan wrote:

> I think that's basically what I have -- configurable factories via Bread::Board::Declare.
> I just thought there might be a way to declaratively build them and their products.

Can you categorise them down into a few mechanism types, and then define new syntax to represent and expand each out into a particular implementation of that underlying mechanism?

> I could use the factories to apply my roles to the foreign objects at run time, but that still
> leaves the foreign object exposed.  I'm hoping to use composition instead, and hide the foreign
> object completely.

I've been storing eveything in an attribute slot with MooseX::Privacy's 'Private' or 'Protected' traits.  However there are constraints around declaring them like that in a Role, something I want to explore when I get time.

> But I can't always predict how the wrapper and foreign object are going to
> connect with each other, so there probably has to be some procedural code to do the heavy
> lifting.

A single named Attribute in every case, whose type is determined or verified at runtime?  A lazy attribute with a builder, or perhaps a BUILD* hook or something that looks after construction and type checking for you, but still lets you deal with them polymorphically like $factoryGeneratedBlah->instanceIsAlwaysHere() ?

> you don't want to expose them directly to your app (because you will change them out later).
> On a related matter, I'm having trouble deciding whether to use abstract base classes or roles
> to define the interfaces.

I'm finding sufficient use for interface Roles which just 'require' a bunch of unparameterised methods.  I haven't had time to see how MooseX::Declare's method parameter interact here, as Private|Protected Attributes declareds in Roles has to take priority for me.  If we can declare an interface with typed parameter slots, method signatures and all that jazz - I for one would find it incredibly useful, for the same type of de-coupling issues that you're dealing with above.

>  So that's pushing me towards abstract base classes.

If we had Traits, with explicit conflict resolution in a matrix of slots at instance construction, then there's a much more useful 'abstract base class' than jumping through any consumption-order hoops, imho.

> Anyway, using Moose has really helped me to think more about architecture.  Probably because it
> has saved me from the drudgery of thinking about accessors and constructors and types and so on.
>  I am very grateful for that. And there is much more for me to learn.

Amen to that Brother! :-)  I've never been as excited about Perl as I am now in 2014, dating back to 1996, and while much of this is because of Moose - I'm getting more and more excited about the possibilities that p5-mop-redux in core could help achieve, even if it is just the first tip of the wedge (re-implementing Moose on top of p5-mop-redux with attributes private to roles!!).

--
Niall Young
[email protected]