* p...@cpan.org [2016-08-23T03:56:24]
> > > 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.

I don't understand "you have no idea about arbitrary object."  Obviously you
would get a type of object based on the header in question.

> 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...

This reads like, "Look, just use the API that you don't like because I already
wrote some code."  That's not going to sway me.

What happens when someone wants a Date object for the Date header?  Do we add
header_date?  Then header_rcvd for Received headers, and so on?  This interface
leads to either a proliferation of these things or to some line where we say,
"well *these* headers are important enough and *these* are not."  On the other
hand, a generic mechanism is generic.

You can always publish your work as a subclass, if you think it that popular
acclaim will convince me I'm wrong.


Attachment: signature.asc
Description: Digital signature

Reply via email to