commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [LANG] Thoughts about Lang 4.0
Date Wed, 24 May 2017 15:49:22 GMT
On May 24, 2017 9:42 AM, "Rob Tompkins" <> wrote:

> On May 24, 2017, at 10:33 AM, Dave Brosius <> 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.



> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message