Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

finally released: less piggish email code 2 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Interface design is always a trade-off between simplicity and functionality. For Email::Simple the key was simplicity, but that restricted the functionality of the public interface, which of course makes it harder to build on top of that interface. We could, of course, have had an Email::Base with a big public interface, and Email::Simple and Email::MIME built on top of that, but I was really trying to get away from complex inheritance relationships. You seem to be wanting both simplicity and functionality,
    • Sure, but if it's difficult to build on a base class's public interface, the preferable solution is either to build your own support structure or extend the foundation provided by the public interface, not to drive pylons through the other guy's ceiling.

      It's silly to say this is just a question of features versus simplicity. It's just about encapsulation: if the feature wasn't provided publicly, it should not have been used. It should have been reimplemented or placed in a public place.

      The existing code didn't choose simplicity over functionality. It used the functionality through back channels.
      --
      rjbs
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.