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 unworkable.

The whole point is to implement the same interface in terms of
different internals.

> 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.

That's why they are in separate roles that are "off" by default.

These roles are orthogonal.

> 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?

Every "off by default" role is distinct. You cannot use them
simultaneously if they conflict.

> 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 not sufficient to implement such couplings between
> "unrelated" modules: you commonly need serious parameter rewrites.
> Delegates are nice within a homogeneous concept.

Email::Abstract works. It's not the most pleasant thing, which is
why it's problematic, but it *does* do the job.

> The only way I have found to work is with "wrapper" objects which
> translate between the two modules.

a.k.a a delegate

> 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!).

Which is much more work than what roles make you do.
> 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...

Base classes, as opposed to roles, don't work well at *all* for
these types of scenarios.

  Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org  0xEBD27418

Attachment: pgpYxhcH0dDFZ.pgp
Description: PGP signature

Reply via email to