On 11/8/05, chromatic <[EMAIL PROTECTED]> wrote: > 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.
In other words, a role is just a closed class and a class is just an open role? Larry stipulated this about a month ago. Rob
