On 11/1/05, Jonathan Lang <[EMAIL PROTECTED]> wrote: > Rob Kinyon wrote: > > > 1. choose one of a set of available methods to call its own. > > > 2. create a version of its own. > > > 3. pass the buck. > > > > #1 and #2 are identical. Stevan and I have always viewed #1 as a > > special case of #2. If you want to choose a method to call, then > > create a method of your own and have it wrap the one you want to call. > > > > The benefit here is that you can do more than just pick a method. > > Let's say that you have a conflict and the correct behavior is to do > > them all, but in a certain way. Or, maybe the correct behavior is to > > provide a limited API over one version. > > > > Maybe, there'll be some sugar to allow #1 to be its own syntax, but it > > should be viewed as a #2. > > You're right. But this obscures the point that I was trying to make: > we need to decide what set of methods are available when > disambiguating. Is the DOESA list public or private? Should the role > be able to look up any public method that any of its ancestors have, > or should it be restricted to just the methods that its parent roles > have? Given the flattened nature of composition, I feel that the > latter is more appropriate.
Actually, given the flattened nature of composition, any role should have access to -every- method that a class would be given through doing that role. So, the DOESA list should be all the public methods that the role is acting as a gateway for. Rob
