> > > 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 think I see where you are going. If I can distill things down to a few conventions, then I can use configuration or a type of DSL to do the work. Does that sound right? I've been storing everything 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. Thanks for the suggestion, I'll look into that. > 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. Sometimes I feel we have turned Perl into Java. But that's probably ok, because they have turned Java into Perl. Goldilox had the right idea. > 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. I do like the compile-time checks that roles provide. If I can satisfy all those, then there's a pretty good chance that I've done it right. The base class is mostly to help Bread::Board::Declare do its typemapping magic. There's probably a way to do it with role-based types, but I haven't figured it out yet. Thanks for sharing your wisdom. I'll sleep on it and see how things go tomorrow. -Jeff
