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.
in reply to Re^3: Object::InsideOut and Roles/Mixins
in thread Object::InsideOut and Roles/Mixins
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.