* Yuval Kogman ([EMAIL PROTECTED]) [060808 01:04]:
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.
On Tue, Aug 08, 2006 at 09:05:07 +0200, Mark Overmeer wrote:
Sometimes, the external interface of a module looks the same, and
there are cases where the internals behave as such as well. In
general, however, the internals are more different then the user
code shows. That makes your proposal
On Tue, Aug 08, 2006 at 09:05:07 +0200, Mark Overmeer wrote:
Of course, we could use the Email::Abstract interface as a base-
class to all email related modules, but you know that this wouldn't
work for the Perl community...
Actually I'd like to expand on this.
There are two problem with
On 8/8/06, Yuval Kogman [EMAIL PROTECTED] wrote:
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
On Tue, Aug 08, 2006 at 11:14:40 +, Luke Palmer wrote:
Mail::TheOneTrueWay.new.header; # which one?
Either neither, or the default one (which is declared default by
the class).
A related question: if Mail::SomeAPI and Mail::SomeOtherAPI both
exported a method, say send, and you
On 8/8/06, Yuval Kogman [EMAIL PROTECTED] wrote:
I personally prefer delegates for almost any design dillema, but
most CPAN modules aren't that way.
Well, what way are they? How else has this problem been solved?
snipped stuff about adaptors
Yes, this is necessary for anything heavyweight
On Tue, Aug 08, 2006 at 11:35:30 +, Luke Palmer wrote:
On 8/8/06, Yuval Kogman [EMAIL PROTECTED] wrote:
I personally prefer delegates for almost any design dillema, but
most CPAN modules aren't that way.
Well, what way are they?
Usually not polymorphic at all.
We have the capabilities
On 8/8/06, Yuval Kogman [EMAIL PROTECTED] wrote:
My original idea was that this is again an ambiguity error - without
the helper function stating which role it's using it cannot dispatch
the header method at all, since it's in a role-conflicted state.
The difference, though, is that this
On Tue, Aug 08, 2006 at 12:00:03 +, Luke Palmer wrote:
The difference, though, is that this ambiguity error happens at
call-time, whereas most ambiguity errors happen at composition time.
As I saw it it's not really a role, it's more of a no-op coercion.
Instead of actually writing an
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
10 matches
Mail list logo
