On 5/21/11 1:50 AM, Luc Maisonobe wrote:
> Le 21/05/2011 01:25, sebb a écrit :
>> On 20 May 2011 21:04, Phil Steitz<phil.ste...@gmail.com> wrote:
>>> This code in BigFraction.add looks dangerous to me:
>>>
>>> if (ZERO.equals(fraction)) {
>>> return this;
>>> }
>>>
>>> subtract has similar code and some other methods return the static
>>> BigFraction.ZERO.
>>>
>>> While BigFractions are Immutable, this could cause problems for
>>> applications that are expecting new instances resulting from
>>> arithmetic operations. Can anyone see any reason that this should
>>> not be changed to consistently create new instances?
>
> Speed and memory. This is especially important for instances that
> are really used a lot (0, 1 ...) as building them anew a lot of
> times seems unneeded for immutable instances.
>
>>
>> Seems to me that an application that depends on getting new
>> instances is broken.
>
> I tend to agree here, but there is certainly a reason for such a
> need. Could you explain why new instances are mandatory ?
Could be there is no problem, it just seemed odd and potentially
dangerous to me that most activations produced new instances, but
some returned *this. Sebb's pointing out that this "feature" is
shared by the jvm and thinking carefully through the use cases,
immutability and how equals is implemented I guess it does not make
any difference and does not really require separate documentation.
I was thinking there could be instances where applications wanted to
store references to sets of results and somehow crossing pointer
references would lead to unexpected results or gc problems; but
thinking carefully through all of the examples I could come up with,
I can't see a problem, so I guess it is OK to leave as is.
Phil
>
> Luc
>
>>
>> Cf autoboxing which uses valueOf() which may return a cached
>> instance.
>>
>>> Phil
>>>
>>> ---------------------------------------------------------------------
>>>
>>> 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
