[josm-dev] [PATCH 01/26] Enhance OsmPrimitive a bit

Petr Nejedly Petr.Nejedly at Sun.COM
Wed Apr 30 09:55:24 BST 2008


Dave Hansen napsal(a):
> On Tue, 2008-04-29 at 15:20 +0200, Frederik Ramm wrote:
>>>  	@Override public final boolean equals(Object obj) {
>>> -		if (obj == null || getClass() != obj.getClass() || id == 0 ||  
>>> ((OsmPrimitive)obj).id == 0)
>>> +		if (obj == null || getClass() != obj.getClass())
>>> +			return super.equals(obj);
>>> +		if (id == 0 && ((OsmPrimitive)obj).id == 0)
>>>  			return super.equals(obj);
>>>  		return id == ((OsmPrimitive)obj).id;
>>>  	}
>> In a case where id == 0 but obj.id != 0, the old code would have  
>> returned super.equals(obj), while your code returns false. I suspect  
>> it doesn't matter much - but was that a deliberate change and if yes,  
>> why?
> 
> No, not a deliberate change.  Probably just me misreading the code.
> But, if I misread it, maybe others do too. :)  Probably good to clean it
> up.

BTW: There's _no_ semantic change anyway, taking into account the semantics
of Object.equals (as Object is the direct superclass).
Both implementations would return false.
Anyway delegating to super implementation in case it will always return false
still makes the code obscure and consider my implementation (in josm-ng) clearer:

    public @Override boolean equals(Object obj) {
        if (id == 0) return obj == this;
        if (obj instanceof OsmPrimitive) { // not null too
            return ((OsmPrimitive)obj).id == id && obj.getClass() == getClass();
        }
        return false;
    }

-- 
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!




More information about the josm-dev mailing list