On Fri, Oct 28, 2005 at 14:19:46 -0400, Stevan Little wrote:
> 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.
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.
I think it's useful from a role perspective, because that way you
can let the user decide on some conflicts.
While I can't think of an example, I don't think there is much risk
- this doesn't take away functionality. The only issue is that you
can compile a role with a conflict and it doesn't complain till you
actually use the role (this should be taken care of by writing the
simplest of tests for your role). It does open doors for higher
complexity composition. Especially if you have a deep hierarchy of
role consumption:
a b c d
\ / \ /
e f
\- g -/
(role g does e does f, e does a, does b...)
Let's say that a and b conflict at 2 points. E can resolve one of
them, and leave the other one for g to decide.
Perhaps methods in f are used to resolve e with dynamic dispatch:
role g does e does f {
method conflicts_in_a_and_b ($arg) {
given .method_from_role_f($arg) {
when Condition { .a::conflicts_in_a_and_b($arg)
}
defualt { .b::conflicts_in_a_and_b($arg) }
}
}
}
This is, IMHO legitimate use.
The only restriction should be that when runtime begins no class (or
anything that can be instantiated) is allowed to still have a
conflict.;
> >>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
If you can't see at all into the code you use you eventually run
into problems like the "shlemiel the painter" algorithm for C
strings (google to find refs for that, too long to explain here).
Frequently when using library code whose documentation is not
perfect (and in opensource almost no documentation is ever perfect)
I have a great privilige - search.cpan.org has a one click path to
seeing the source code of any module i'm considering to install.
This allows me to see how something works, estimate how hard it will
be to extend it if the need should arise, assess the quality of the
code, and make sure I understood things correctly.
This spirit of openness should be maintained. You don't have to take
apart a role and recompose it and what not, breaking encapsulation.
But you should be able to fudge it slightly, because the author of
the role might not be getting paid to fix it to your needs, and you
may have to get slightly hackish.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!!!!!
pgpcm9H3z1CWi.pgp
Description: PGP signature
