* p...@cpan.org [2016-09-05T04:25:11]
> I do not want to add ->as_mime_header (or other function) which will do
> MIME encoding/decoding into Email::Address::XS. That module is for
> formating and parsing email addresses headers, not for MIME
> encoding/decoding. Same as it is for Email::Address module.

The best way to know how to properly encode a structured header field is to
know both its structure and the way that the structure ie meant to be encoded.
For example, to know that a `mailboxes` structure may have a display-name,
which would be words, which can be encoded, and may have an addr-spec, which is
not words, and so cannot be encoded.

Parsing and encoding are not separable concerns, here, because to know whether
to decode a part, one most know what part it is, which means it has been
parsed.  You can only properly decode the structured data by knowing the
relationship between structure and encoding.  Then, you can only encode the
data by knowing the same.  This means that any interface between Email::MIME
and some structured field representation has a much more complex API, if
Email::MIME is responsible for the encoding and decoding.  It doesn't just need
a map of field name to class name, but also instructions on how structured data
are encoded and decoded.

This seems like it becomes a nasty mess of deep coupling.  Am I making some
fundamental mistake, here?

Anyway, isn't it certain that people who parse addresses from headers will want
to get a decoded form?  Surely this will be common:

  my @recipients = map {; $_->phrase_str // $_->address }
                   Address->parse( $email->header('To') );

The Dovecot parser (as I recall) does not decode encoded-words, so phrase_str
is easy to write.  Does every consumer of Address need to know how to decode?
Further, won't people want to write:

  my $to = Address->new("김정은", "k...@example.biz");

...and then pass that object on to something that knows what to do with it?
Does every possible consumer of Address need to know how to encode an Address
object?

-- 
rjbs

Attachment: signature.asc
Description: Digital signature

Reply via email to