Gabriel Roldán wrote: > Hi all, > > are the Filter and Expression implementations meant to properly implement > equals and hashcode? > Are their data objects? Thinking ... I would have to assume yes. I sure wish they were immutable (so they would not change place in a hashmap ); > If so, we are in trouble, as (almost?)none of the FunctionExpression > implementations does. > > For the ones that do, should we move to comparisons based on the geoapi > interfaces rather than on concrete implementation? I know the geoapi > interfaces don't impose interface based comparisons. Should they? > You are correct on both counts; lets go back over to the GeoAPI project and break out some javadoc goodness. > I know this way is harder to achieve symmetry, so I'd like to know if there > already is an agreed position on the topic, or there is place to go the java > Collections way. > The "Java Collections way" is a different case - the set of Collections is "open" and not subject to extension (as such they usually do not define equals at the Collection level; but *do* at the List level).
Here is a link to the presentation on that stuff BTW: - http://www.infoq.com/presentations/effective-api-design I think both Jesse and I have attended this talk at different times; I have some notes taken that may be useful as guidelines for GeoTools. Cheers, Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
