On Monday 22 August 2016 22:34:39 Ricardo Signes wrote:
> * p...@cpan.org [2016-08-20T06:01:16]
> > Email::MIME is module which automatically do any MIME encoding/decoding
> > without user interaction, so that decoding must be done automatically
> > and without such "upgrade" function.
> So do you mean that whenever someone reads the header with a specific method,
> the header is parsed just-in-time?
> If so, this seems like something very easy to add in an Email::MIME subclass
> show it off.
> Of course, it's also easy to take the hypothetical code behind
> "upgrade_headers($email)" to do something just like this, on a
> > I do not want to do that decode manually or call some "upgrade" function
> > which you propose... Reading one email header should not change internal
> > email structure.
> I never suggested that anything was changed by virtue of being read, but
> that one could explictly upgrade structures if desired.
> > Also it must be possible to get either named groups from Original-Cc
> > header or only list of addresses. And I think with your proposal API it
> > is not possible. You would need to call some "downgrade" function and
> > then "upgrade" it to another object or so...
> Why would this not be possible? There is some object storing the mailboxes
> structure, and it provides methods that answer the questions one needs to ask.
Because you have no idea about arbitrary object. If you want to e.g.
decode Email::Address::XS object, you must decode only ->phrase() and
->comment() parts! Not others.
Other objects will have different methods which needs to be
encoded/decoded. And MIME module (in this case Email::MIME) must known
which of them needs to be encoded/decoded.
Anyway, lets move forward. I already implemented something and send
information in email with subject "Email::Simple & Email::MIME with
Email::Address::XS" to pep mailing list...
I think this is good approach to provide usable API + ability to extend
code for other objects...