Your point about BiFunction and BiPredicate is of course valid, but
there are a couple of things about those things that remediate their
awfulness.
1) They are interfaces, and thus describe function, not storage.
2) They are almost always transiently used, as anonymous/lamda classes,
and so the scope of their use is small.
On the other hand, Pair is a storage mechanism, and so it is quite
likely that you encourage developers to build things like Map<String,
Pair<String, String>> or such, that live long times and have large
scopes. That is heinous.
Anyhow, i suppose it's really a tangential topic to this thread, so i
suppose i hijacked it somewhat, and so apologies... carry on.
On 05/24/2017 11:49 AM, Matt Benson wrote:
On May 24, 2017 9:42 AM, "Rob Tompkins" <chtom...@gmail.com> wrote:
On May 24, 2017, at 10:33 AM, Dave Brosius <dbros...@apache.org> wrote:
Let's be honest, a Pair class is a bad paradigm, invented for lazyness
which throws away any informative metadata. I'm not sure all of this
fighting is worth it over a this.
Dependency/classpath discussions aside (clearly using “Pair” as an example
for the sake of discussion), I agree with Dave here on the strangeness of
the concept of a Pair or Tuple:
It seems that what we’re taking about is an arbitrarily large, yet finite,
collection of one type, and there a substantial number of different ways to
represent this.
Just for the sake of completeness and correctness, the Pair class has
separate type parameters for each item. As to the charge that it is lazy:
sure, but by the same token, so could BiFunction or BiPredicate be
considered lazy, yet they exist in the JDK. Sometimes you just want to get
it done without over-modeling everything, especially if they're used for
implementation rather than as a public API.
Which brings up a fair point: generally speaking it's probably not a good
idea for an API to be defined in terms of some other API, but if a consumer
of [lang] chooses to do that, then they have to deal with the consequences
of compatibility.
Matt
-Rob
On 05/24/2017 09:08 AM, Emmanuel Bourg wrote:
Le 24/05/2017 à 13:55, Stephen Colebourne a écrit :
Library A that depends on lang3 returns a Pair.
Library B that depends on lang4 takes a Pair.
Application cannot pass Pair from A to the B without conversion.
That's a valid point, but the severity depends on the library. joda-time
with its date related types is more data centric than lang and its
static utility classes. The risk of incompatible data structures is
lower with lang, but the risk of an unsolvable binary incompatibility is
higher due to its ubiquity. The strategy adopted to mitigate the
compatibility issues really depends on the usage of the library.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
