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