Yes, I see. Good point.

Actually, I thought about this when I considered using Pair. In fact, I
have a vague recollection of having seen the article you reference.

My thought was that, as someDoFn(String username, String password) does not
abstract the model by data type, rather only indicating it by way of
variable names, that anotherDoFun(Pari<String> authentication) was not that
far off a deviation and was in fact a somewhat comparable non-abstraction,
relying only on variable name as well to indicate its data model (presuming
the variable name sufficiently implicit of the values therein). In fact, if
I were I to instead use oneMoreDoFn(Pair<String> usernameAndPassword), it
might be just about as good as the original.

And, of course,
DoFn<Pair<String,Collection<Pair<String,Pair<Double,String>>>>,Pair<String,List<Pair<String,Pair<Double,String>>>>>
is
a whole lot different than Pair<String> (and possibly not the most fair
comparison. :-)

Those were my thoughts on it at the time (and some thoughts more recent),
at any rate,

But, if that is the general consensus of the java community, and as I am
certainly in favor of good data modeling and abstraction, I will indeed
create (or find) an appropriate date type to model the authentication
credentials.

Look for an upcoming second pull request.

Thanks!

Lee



On Thu, Aug 29, 2013 at 1:46 PM, Matt Drees <notifications@github.com>wrote:

> In src/main/java/org/ccci/util/mail/MailMessageFactory.java:
>
> >
> > -    /**
> > +	public MailMessageFactory(String smtpHost, Pair<String> authentication)
>
> Why Pair<String> authentication instead of String username, String
> password? (Or, perhaps better, Authentication authentication)
>
> The folks at google have strong opinions against Pair-ish classes; this is
> worth a read:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003995.html
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/Cru-Tech/util/pull/2/files#r6067747>
> .
>