commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brosius <dbros...@apache.org>
Subject Re: [LANG] Thoughts about Lang 4.0
Date Thu, 25 May 2017 15:07:51 GMT
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" <chtompki@gmail.com> wrote:
>
>
>> On May 24, 2017, at 10:33 AM, Dave Brosius <dbrosius@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message