Justin Deoliveira wrote: > We do see constants in other places in the api, ie. SortBy#ACENDING, > SortBy#DESCENDING. So in terms of consistency we might want to apply > this rule of "interfaces only" across the board. > Cool I am sold, lets make the constants (there is an AUTO_COMMIT as well in GeoAPI). We can should break them out into separate classes with package visibility so that the class files are all nice and clear. > all that nice. However we could keep the geootols constants around, and > have them delegate to the factory methods. But then we are stuck > depending on deprecated interfaces. I know geoapi is supposed to be > toolkit agnostic but I don't see any other toolkits chomping at the bit > to play... :) > Yeah the factory idea will not really fly that well. Moving on. > I don't see that big a gain to Filter.NULL. The client is still stuck > with the decision of how to treat "the absence of a filter". > Um, Filter.NULL actually is the reason why Filter.NONE and Filter.ALL exist - they both represent a NullObject (cough pattern) just with different default behavior.
Lets call that a dollar, your turn to code it :-) Jody ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
