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 > to > 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 > per-known-header > basis. > > > 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 > rather > 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...
