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.


Reply via email to