Ok, that is good to know. But my point was that if there was a need to 
have a method to check if a change needs to be written to disk, then I 
think it should not have been the equals method. Because the equals 
method is used to check for logical equality, not necessarily exact.

I am not saying this was stupid, or anything like that. In fact, I am 
saying I find this kind of stuff difficult :) And on top of that, you 
have to worry about backwards compat. Anyway, I will be quiet now :)

Erik

Jody Garnett wrote:
> I think this may of already been done on trunk Erik.
> Jody
>
>> Yes, but in that case it would be better in my opinion to supply a 
>> method "equalsExact" like JTS, instead of doing this strict check in 
>> the overridden equals method.
>>
>> Most datastructures use the equals method somehow (Quadtree, 
>> ArrayList, HashMap, etc), and they run much slower than they need to 
>> now because of this very expensive implementation. Also, they will 
>> behave incorrectly in cases where you want two features to be equal 
>> only if they are of the same type and with the same id.
>>
>> The only way to workaround this (as far as I know) is to wrap a 
>> feature in a class which overrides equals to only check the feature 
>> type and id. I hope most will agree that this is ugly.
>>
>> Erik
>>
>> Jody Garnett wrote:
>>> Usually I base quick equality checks on the feature ID; my guess is 
>>> the equals method is strict because it is/was used to detect if a 
>>> change needs to be written out to disk.
>>>
>>> Jody
>>>> Hello everyone, I have a question:
>>>>
>>>> Why does the DefaultFeature equals method only accept features 
>>>> where all attribute values are equal to the corresponding attribute 
>>>> in the feature called on? Seems very strict to me, why not accept 
>>>> all features of the same type and with the same ID?
>>>>
>>>> This behavior is causing some problems for us. First because it is 
>>>> quite slow, and second because use of the JTS Quadtree becomes 
>>>> complicated (cannot remove a feature in the quadtree using a 
>>>> different feature instance with the same type and id but possibly 
>>>> with different (null) attributes).
>>>>
>>>> Regards,
>>>> Erik Loevlie
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> SF.Net email is sponsored by:
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>> http://sourceforge.net/services/buy/index.php
>>>> _______________________________________________
>>>> Geotools-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>   
>>>
>>>
>>
>
>


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to