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
