On Wed, 2005-07-13 at 16:07 -0400, David Storrs wrote:
> My understanding is that a Role is an abstract (i.e. cannot be
> instantiated) blob of methods and, possibly, data. The purpose of a
> Role is to paste it into a class--in other words, a Role is a not a
> type, it is a part of a type.
Nope, it's a type. What is a type besides a named blob of methods and,
possibly, data?
> The point of this is to force the programmer to give a reasonable
> constraint...when they expect something that Wags, does it need to be
> a Dog, or will any Animal that can Wag be sufficient? Or are they
> really looking for absolutely anything that is capable of Wagging?
The latter.
As soon as you require signatures to enforce *how* the arguments fulfill
a type constraint, you've violated a principle design goal of roles,
namely that it's more important that something fulfills the requirements
of type ("RobotDog understands bark() in the context of Doglike, not
Treelike") than that it fulfills the requirements of the type by
inheriting from a base class, delegating to a contained object, applying
a role, or whatever other way you can imagine.
-- c
