On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
> If roles are interfaces, do we want any class that provides an interface
> consistent with a role to implicitly do the role? That is, if a class
> fulfills all of the interface requirements of a role without actually
> saying it does the role, does it do the role anyway?
After thinking about this a little more, I think there may be a bit of
misunderstanding about what I want here.
Having a class implicitly *do* a role if it has methods and attributes
of the appropriate name is a bad idea -- there's too much room for
accidental collision there.
Sure, people shiny-eyed about duck typing might reasonably say "Why?
That doesn't make sense!" but it's a careless duck typer who randomly
throws objects in collections and hopes for the best. You *can*
mistakenly use an object that quacks incorrectly and spend some time
debugging it, but if we're providing a system that can catch some of
that incorrectness, I don't see what benefit there is to subverting its
ability to detect incorrectness.
What I want instead, and what might seem similar in the sense that it's
exactly the opposite, is implicit declaration of a role for each
explicitly declared class.
That is, if I declare a Dog class, there immediately springs into being
a Dog role empty of everything but the expectation that whatever does
that role provides everything publicly accessible that an instance of
the Dog class does.
You don't get the nice code-reuse of roles, but you can use your doglike
object -- Mock Dog, Dog Proxy, Logged Dog, Decorated Dog -- anywhere you
can use a Dog and everyone's happy.
They're man's best friends, you know.