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.
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.