On Tuesday 31 May 2016 02:42:48 Ricardo Signes wrote: > * p...@cpan.org [2016-05-28T16:48:40] > > > Basically yes. From caller perspective I want to pass email address > > object and let Email::MIME to do MIME encoding correctly. Something > > like this: > > > > my $email = Email::MIME->create( > > > > header_addr => [ ... ], > > > > ); > > I think that requiring people to break headers up even further into > to add a "header_addr" argument is a bit much. And why header_grps?
In most cases you do not send emails with named group of addresses. So it make sense to make it more easier to specify just list of addresses which does not belong to any named group. But in some cases you can compose & send email with list of addresses which are in some named group. So some extended syntax is needed. > How about object that represents the group? For those who want to compose email is easier to specify addresses in perl list, not creating such objects or similar... It also leads to more readable code. > Then the existing > header and header_str arguments can start silently accepting these > objects and doing the right thing. Yes, that can be implemented. But there is problem with stringification and other such things of object. Currently when I passed some variable into header or header_str I was sure that string value of that variable was used. When some object magic is used then it will not be such easy to check if string value (stringified) or object value is used. So this is reason why I proposed header_addr and header_grps to make it clear what you want to pass. Also it is similar to list/group API of Email::Address::XS module. If you think that API for named group support in Email::Address::XS is not good or can be improved, let me know. What I would like to see is same/similar usage named group addresses in Email::MIME and Email::Address::XS.