xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Pepping <spepp...@leverkruid.eu>
Subject Re: [VOTE] Merge XGC color branch into Trunk
Date Tue, 02 Nov 2010 20:17:35 GMT
On Mon, Nov 01, 2010 at 08:29:14PM +0000, Vincent Hennebert wrote:
> More importantly, I keep thinking that there’s a design flaw in
> ColorWithAlternatives. Its equals method breaks the contract defined on
> Object.equals since it’s not symmetric. This is bound to cause

That would mean: ColorWithAlternatives a, Color b; a.equals(b) should
return the same as Color.equals if b is not of type
ColorWithAlternatives or a subclass. Only if b is of type
ColorWithAlternatives or a subclass, can ColorWithAlternatives.equals
apply its own logic.

How can symmetry be assured if the type of b is another subclass of
Color which implements its own equals? If the other class applies the
same logic (SubclassOfColor a, Color b; a.equals(b) should return the
same as Color.equals if b is not of type SubclassOfColor or a
subclass), it is guaranteed.

> hard-to-track issues in client code. Also, the way equals is implemented
> will make it systematically return false if an instance of
> ColorWithAlternatives is being compared with an instance of a sub-class,
> which may not be the desirable result.

Would it be better to use getClass().isInstance(obj), which would be
true for all objects which can be cast to ColorWithAlternatives?

> Either ColorWithAlternatives is not a Color and therefore should not
> extend the Color class; or its equals method should be changed to follow
> the contract and the comparison of ColorWithAlternatives instances
> should be implemented differently.

Would findbugs find this problem?


To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message