* 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.
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 unworkable.
In this example:
Mail::Internet is deprecated: does not even support multiparts
Email::Simple does e-mail as simple as possible
Mail::Message does e-mail as RFC-compliant as possible
> 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.
For different approaches to tackle the (in this case e-mail) problems
you need different internal helper objects, different methods, different
attributes. It is in general hard to force an extra interface
definition inside the same class.
> 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).
But that's not all. A header contains fields, which are usually objects
as well. How would you include variation in those in the definition?
And different versions of one module which use your Email::Abstract
module? You must not try to understand the structure of other modules
into such a detail, because you cannot maintain it.
> Delegates are another way around this but let's face it:
Delegates are not sufficient to implement such couplings between
"unrelated" modules: you commonly need serious parameter rewrites.
Delegates are nice within a homogeneous concept.
The only way I have found to work is with "wrapper" objects which
translate between the two modules. The advantanges are that you have
localized the hassle of interfacing to one class, and you hide the
internal complexity of both sides (OO is about abstraction!).
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...
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
