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 ni...@iinet.net.au
