Here's how I see roles. This is just an attempt to formalize our
concepts so that the answer becomes an obvious truth rather than a
decision.
A role is an interface with some default implementations. Here's an example:
role Foo {
# anything that conforms to Foo must provide a foo()
On 29/10/05, Luke Palmer [EMAIL PROTECTED] wrote:
Moving on.
role Baz {
does Bar;
}
By my free-derivation (or composition in this case, I guess)
principle, Baz is now equivalent to Foo. If you think of them as
interfaces, it makes perfect sense. Baz provides no
On 10/28/05, Luke Palmer [EMAIL PROTECTED] wrote:
Here's how I see roles. This is just an attempt to formalize our
concepts so that the answer becomes an obvious truth rather than a
decision.
A role is an interface with some default implementations.
-snip-
Now we ignore the inner workings
On 10/28/05, Luke Palmer [EMAIL PROTECTED] wrote:
[snip]
It was the fact that at each stage of the game, we summarized the
defaults and requirements for each role, ignoring the internal makeup
(i.e., what roles were composed into it, etc.).
So, in theory, one should be able to ask any given
On 10/28/05, Rob Kinyon [EMAIL PROTECTED] wrote:
Now, it's obvious why a class would have to resolve that conflict. I
would say that a role would have to resolve the conflict is that a
role should present a consistent API to the rest of the world. In
other words, I want to be able to depend on
Luke,
On Oct 28, 2005, at 9:44 PM, Luke Palmer wrote:
It was the fact that at each stage of the game, we summarized the
defaults and requirements for each role, ignoring the internal makeup
(i.e., what roles were composed into it, etc.).
This then imposes somewhat of an ordering with role
