Re: Email::Address::XS

--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* [email protected] [2016-08-23T03:56:24]
> > > Also it must be possible to get either named groups from Original-Cc=
=20
> > > header or only list of addresses. And I think with your proposal API =
it=20
> > > is not possible. You would need to call some "downgrade" function and=
=20
> > > then "upgrade" it to another object or so...
> >=20
> > Why would this not be possible?  There is some object storing the mailb=
oxes
> > structure, and it provides methods that answer the questions one needs =
to
> > ask.
>=20
> 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...
>=20
> 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 alre=
ady
wrote some code."  That's not going to sway me.

What happens when someone wants a Date object for the Date header?  Do we a=
dd
header_date?  Then header_rcvd for Received headers, and so on?  This inter=
face
leads to either a proliferation of these things or to some line where we sa=
y,
"well *these* headers are important enough and *these* are not."  On the ot=
her
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.

--=20
rjbs

--bp/iNruPH9dso1Pn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXvl4JAAoJEOYby6cMccU58E8H/2zo+iTw4e1VROtMhVjGTUvl
hZnLEdm8oARMu64sy4jzQC58xo5sYAapv9LqJxC0MlRbgrBrUBGAXGVsQYLc/ih5
I8nhvKgnvHNf4/AOiQXnafIvI4eG4ZXdrGGNAJDLL7fKrcOOxtaxGT8PUFgkIl6w
yEhb/QBHBD+zit+fKlN9/veZy6aKxWXbvmkYj95dt3fimNnOPgZIgVZdxfBRK88U
SRfu3Hsc+9l1ZAPDpu+VoQfrI7TniVg0MEvL9moFI8YcsX7CIMRNsR2I3xVyTuzx
bVDaumEY4dUGjx/Rso0Ku0u1uBoXZJj/hElt2TkhmZouxW3gjFAukzT57hV45+w=
=SJPR
-----END PGP SIGNATURE-----

--bp/iNruPH9dso1Pn--