The CPAN has many reinvented wheels. This happened since we have so many authors (== opinions) over so many years.
For example, we have Mail::Message to Email::Simple, to
Mail::Internet to.... They all do the same thing differently.
Then there is Email::Abstract, which provides a simplified API for
all of these together, so that modules like Mail::Thread can work
with either.
With the introduction of roles, supposedly this is going to be less
of a problem. Email::Abstract would ideally be a role that the
organically grown message abstracting classes just 'do'.
However, suppose that Email::Abstract itself would be reinvented.
The message modules now have to choose between either
Email::Abstract or Email::Abstract::Better as the one role to do
(since they probably conflict), or it will have to do weird magic to
disambiguate in a context sensitive way.
I think a nice idea to work around this would be to introduce weak
roles, that are lexically scoped.
The way it could work is a bit like this:
class Mail::TheOneTrueWay {
does Mail::SomeAPI is weak {
method header; # this method has different semantics for
# each role. It would normally conflict.
}
does Mail::SomeOtherAPI is weak {
method header;
}
method body; # this method is shared between the two roles
}
Then, when a module is expecting a message object it declares the
role it wants this object to do for this scope:
sub analyze_mail ( Mail::SomeAPI $message ) {
$message.foo; # unambiguous
}
This way coercion can be avoided, which means that keeping mutable
coerced objects synchronized is no longer necessary, thus
simplifying the code path and encouraging even more
pluggability/polymorphism.
I'm not sure on the behavior of $obj.does outside of the role
strenghning scope.
I am pretty sure that this should be purely lexical, and not
dynamic, even for .does (if it's true on the inside).
Perhaps an invokation of an ambiguous method is an error for the
caller ($object responds to N flavours of the "header" method, you
must explicitly say which flavour you prefer right now).
Delegates are another way around this but let's face it:
1. they're not as popular as they should be
2. they're more classes to write
3. they're harder to use
Consequentially we have fairly few delegate based APIs for these
problems (Email:Abstract is the only one I know).
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
pgpzS1FVkV3jl.pgp
Description: PGP signature
