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
Thread Previous
|
Thread Next