Yuval Kogman wrote:
> Stevan Little wrote:
> > If we allow the class to decide if things break or not, then we
> > potentially allow for the system to be in a very unstable state. A
> > method conflict means that neither method gets consumed, and at
> > that point we have a gapping hole in our class.
>
> And compilation will not finish unless the class plugs the hole...
>
> role a;
> role b;
> role c does a does b;
> class d does c;
>
> If there is a conflict at c, it might be a conflict that c knows how
> to resolve, or it might be a conflict that c's documentation says
> the user has to decide on, depending on what they prefer.
>
> What I'm saying is that the hole in c can be consumed by d, and if
> it isn't plugged in either c or d, you get an error.
True enough; but it needn't be true that d have the same tools
available to resolve the conflicts that c has.
There are three ways that a role can deal with a conflict:
1. choose one of a set of available methods to call its own.
2. create a version of its own.
3. pass the buck.
In the first case, the question is how we define the set of available
methods: do we make the full hierarchy of ancestors available to the
role, or do we say that only the immediate parents are available?
Another way to put this would be: should the "DOESA" list be treated
as public or private? (My preference: the "DOESA" list should be
private. You don't lose any capabilities by doing so, other than the
capability to access stuff not explicitly declared - a capability that
roles don't need, and probably shouldn't have.) If "DOESA" is
private, then d won't have access to anything from a or b without
explicitly including them in its own DOESA list. This seems to be
restrictive, and it is - but only in the same way that making an
attribute private is restrictive.
The second case is pretty straightforward.
In the third case, I'd be inclined to say that passing the buck is
equivalent to creating an undefined version of your own - that is, not
addressing a conflict involving method x is equivalent to saying
"method x ($arg) { ... }". IOW, a class that does a role that passed
the buck is faced with an "undefined method" complaint if it doesn't
do something about it, not an "unresolved conflict" complaint.
--
Jonathan "Dataweaver" Lang
