I am eager to get Email::Sender ready for use. The prototype that I use at
work is one of the most useful pieces of code in our internal toolkit, I think.
It makes all sorts of email-related testing much simpler.
Toward that, I've been doing some of the simple stuff required to get
Email-Sender in shape, and now that much of the simple stuff is done, I'm going
to start writing (stealing) more tests. That's not enough, though. For those
of you who saw my talk on PEP at YAPC::NA, you know that one of my biggest
dislikes about Email:: is the way that its modules *utterly* fail to display
signs of design for organic interoperation. (Today's amusing nit:
Email::Abstract doesn't use Email::Simple's method names for common
operations.)
When we spoke about solving this problem at YAPC, we talked about a small set
of common behaviors for new Email:: modules. These would form Email::Base, the
name of which has been used to mock the idea of Email:: being overly complex.
To that, I say, "whatever." We, the current custodians of that code, don't
want to turn it into a giant monolith. In fact, I think it's safe to say that
Email::Simple won't take on the Base behavior at all, both to stay as small as
it is and because it would require too much reworking.
That said, I think Email::Base is a good idea. It can certainly be seen as
step one in the PEP Plugin System, which should help make things easier to deal
with.
At YAPC, the basic idea was that Base would need to include two kinds of
things: exceptions and attributes.
I think exceptions are simple: Exception::Class is very popular, very good,
and fairly lightweight. It works, I believe, on 5.005. Its prereqs are
Scalar::Util and Devel::StackTrace (both of which we'd probably need anyway)
and Class::Data::Inheritable, which doesn't strike me as a big worry.
Possibly the cheapest option for attributes is Class::Accessor, but I think
it's too simple. I think it's important that we have a system that makes you
really notice when you're violating encapsulation. A lot of Email:: bugs have
come about because of a cavalier attitude toward doing things like
$email->{head}{names} = $whatever. Once that's in Email::Foo, you can't change
the internals of Email::Simple without trauma.
I'm not sure what we really want, and I am eager to hear ideas. I would like
to keep things fairly simple. Here's a simple idea whose merits and flaws I
have not deeply considered, yet (it just popped in there):
Objects are hashes in the form { namespace => $guts, ... }. Guts are
namespace specific. The objects' classes also have a mapping of attributes
to providing namespaces. When you say $obj->attr('foo') it does something to
get it from the namespace that owns 'foo'. When two plugins attempt to claim
authority over the same attribute, an exception is raised, at compile time if
possible.
Ok, I know this was a little wordy, but I'm eager to get this ball rolling, so
I'm just going to send it. Replies anticipated eagerly.
--
rjbs
