https://issues.apache.org/bugzilla/show_bug.cgi?id=46962

--- Comment #23 from Vincent Hennebert <vhenneb...@gmail.com> 2012-03-22 
16:54:42 UTC ---
Hi Alexios,

(In reply to comment #21)
> Vincent, thanks for  looking at it.
> 
> > * Why use Double.doubleToLongBits in equals methods to compare doubles
> > (NumericProperty, PercentLength)? Why not just thisDouble == otherDouble? 
> > (One
> > could also argue that some epsilon might be necessary, but this is another
> > topic.)
> 
> 
> Well, if we forget about the epsilon, the doubleToLongBits is the correct way
> to check for equality two doubles. This is well explained in Effective Java by
> Joshua Bloch, used in Double#compare, Double#equals and by all IDEs that
> generate them and libraries like Apache commons-lang EqualsBuilder. Java
> has double values for both 0.0 and -0.0, as well as the never equal
> "not a number" (NaN). Those can't be checked with ==.
> Have a look into the doubleToLongBits source and at the javadoc for
> Double.equals().

Learning new things every day :-) Thanks for the pointers.


> > * shouldn't the specVal field from Property also be tested for equality?
> 
> It seems that currently this is not needed. The specVal is set by 3 
> properties,
> the FontShorthandProperty, the LineHeightProperty and the URIProperty.
> None of them uses the cache, so currently it is not needed in the equality
> tests. 

Ok, make sense. Still I'll modify the implementations of equals and hashCode in
the URIProperty class as it makes explicit use of specVal.


> Please tell me if you expect an updated patch.

It's not necessary.


Thanks,
Vincent

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to