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 ad
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 am
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 capab
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?
Yes, this is necessary for anything heavyweight and probably better
design,
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:
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 w
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 y
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 propos
* 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.
Som
