Re^3: Roles and functional programming

[BrowserUk]

Roles don't -have- attributes.

Hm. The quote was directly from Synopsis 12, so as far as the wording is concerned, you need to argue with the authors.

As far as the semantics are concerned, I did go on to say: "Of course, whatever state they have becomes a part of the instance into which they are composed", so I think we're in tune there.

But, as I also said, and regardless of whether the state is has'd by the Role, or provided by it, that state exists and is presumably usually affected by the Role and persists beyond the invocation of whatever methods the role also provides, so there is no sense in which it can reasonably be described as stateless.

If my limited understanding of ML's Functors means that they are like (my also limited understanding of) Haskell's Typeclasses, then the term composed in the sense you are using it: "composed into"; and that same term in the sense the OP used it: "more easily composable units."; are entirely different things.

With the former composing both operations and state, and the latter performing operations on values only (hence stateless). Quite different beasts. The best discussion I have located upon the difference is this.

[dragonchild]

Yeah, that wording is somewhat poor. It really should say something like "Roles can provide attributes." Except, of course, the Role actually has the attribute if you consider the class as a composition of separate roles with the class itself being an anonymous role that is instantiable (which, if you think about it, is one of the two major differences between a class and a role (the other being that a class has to be complete and a role can be incomplete)). And, in any case, the instance of the class is the thing that actually has the attribute, the class merely being the template by which instances are created.