develooper Front page | perl.pep | Postings from August 2016

Re: Email::Address::XS

Thread Previous | Thread Next
Ricardo Signes
August 25, 2016 02:55
Re: Email::Address::XS
Message ID:
* [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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About