Front page | perl.pep |
Postings from August 2016
From: Ricardo Signes
August 25, 2016 02:55
Message ID: 20160825025505.GA2164@debian
* email@example.com [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.