Re^2: Object::InsideOut and Roles/Mixins

Thanks... I would also want O::IO "fields" (what Moose calls "attributes") in the roles, so will look at the other modules Role::Tiny refers to, Role::Basic and Moo::Role. I'll have to think more about fields and how these role-helpers work to pick the right one.

edit now I am in danger of writing Object::InsideOut::Role - not that I have the time to- but after re-reading about them, and comments implementers have made with the benefit of hindsight, and thinking about how I've already used and misused roles, it's tempting to roll something up taking it all into account.

Comment on Re^2: Object::InsideOut and Roles/Mixins

Replies are listed 'Best First'.
Re^3: Object::InsideOut and Roles/Mixins by tobyink (Canon) on Apr 11, 2014 at 21:22 UTC
It's difficult to get roles and attributes to play nice. Attributes basically have two parts to the implementation: They need to be initialized in the constructor; and You need to provide accessors for them. The accessors are easy. But your role framework doesn't have any control over the constructor; the constructor gets built by the class framework! That's why if you look at Perl implementations of roles, you'll see them fall into two neat categories: Moose::Role, Mouse::Role, Moo::Role, and p5-mop roles all allow you to define attributes in roles. These role implementations are all part of larger frameworks that include a class builder. Role::Tiny and Role::Tiny do not allow you to define attributes in roles. These role implementations are stand-alone. So basically, if you want to write a role implementation that supports attributes, you'll need to write a class implementation to support it. I'm not saying you shouldn't do it. It's a good learning experience. `use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name`	[reply]
Re^4: Object::InsideOut and Roles/Mixins by Yary (Pilgrim) on Apr 12, 2014 at 17:25 UTC
Thanks for that perspective. Here's another thought along those lines- at the minimum a role requires the composing class to implement some behavior (method). Maybe the role also has an implementation defined, which the class can just use. In that case, the role might want to have some data, or state, along with it, and then it's convenient for the role to also add an attribute- to support the method defined in that role. And that's where you need to mesh with the larger framework. Or roll your own per-object attribute/state variable, but isn't it better to use what your framework already provides? Then again, lack of attributes is not that big a deal. There's always package lexical hashes, or closures; also, getters and setters are just methods. And Role::Basic allows importing methods from some other class with that express purpose. TMTOWTDI!	[reply]