Re: Role Method Conflicts and Disambiguation

[Stevan Little]

On Oct 28, 2005, at 11:17 AM, Jonathan Scott Duff wrote:
On Thu, Oct 27, 2005 at 10:19:16PM -0400, Stevan Little wrote:
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.

Here is the basic issue:

role Foo {
    method foo { ... }
    method bar { ... }  # we will use this later :)
}

role Bar {
    method foo { ... }
}

role FooBar {
    does Foo;
    does Bar;
}

Now, at this point we have a method conflict in suspension since
(according to A/S-12) method conflicts do not throw an error until a
role is composed into a class. This means that when I do this:


If we say that the roles Foo and Bar are composed into the role
FooBar and that method conflicts trigger an exception at composition
time (whether composed into a role or class), then your above
declaration of FooBar will trigger an exception and force the user to
resolve the conflict.

Well, if we allow FooBar to die, then we do not allow for possible  
disambiguation by a class (which is the only place it matters anyway  
since roles cannot be directly instantiated). I think that not  
keeping the conflict in "suspension" until the role is composed will  
actually restrict the usefulness of roles. I should be allowed to  
create a role with all sorts of conflicts which I leave for the  
classes to deal with.

Remember that if you create a role with a stub method (method my_stub  
{ ... }) then it acts just like a conflict does in requiring the  
consuming class to implement it.

Stevan