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. Huh? > 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
pgpYxhcH0dDFZ.pgp
Description: PGP signature
