Yuval,
On Oct 28, 2005, at 10:59 AM, Yuval Kogman wrote:
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
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:
class MyClass does FooBar {}
an exception is thrown. Unless of course MyClass has a &foo
method, which will disambiguate the conflict.
My question then is, can FooBar (the role) disambiguate the &foo
conflict?
IMHO yes, but it doesn't have too. It should be able to leave it to
the class to decide.
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. IMHO we should not allow
this to be decided by the user in any other way then to
disambiguate,.. otherwise we should die very loudly.
In the end, we will have probably looked inside every method
defined in Foo, Bar, FooBar and Baz in order
to properly write MyClass2. IMHO, this is sort of defeating the
usefulness of roles at this point.
I disagree - you have to know what a role is actually giving you to
exploit it. Too much black boxing makes your programming language
seem like a Kafka story.
Why? does it introduce bugs? ;-P
So what do you all think??
Role method conflicts should only be dealt with if the user knows
what the roles are actually doing anyway. This will probably be
familiar code, and if not it warrants familiarity.
Agreed.
I don't think we can let the user use library code without being
aware of the library code internals at all. Abstraction that works
like this is usually either crippled or useless. 90% of the time you
don't want to know, but there are exceptions.
A little extreme, but I tend to agree with your point.
Stevan
