* 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. -- rjbs
signature.asc
Description: Digital signature
