You bring up some good points Jody, I am not sure myself which is the best way to go. but just a couple of my own points.
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. Having the constants around would make things a lot easier on geotools. Making client code have to call a factory method as an alternative isn't 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... :) 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". Just by 2c. -Justin Jody Garnett wrote: > This is a hard one, constants have their place. > > What is hard for an "interface only" project like GeoAPI is having > constant classes, personally I find them *very* useful and help > defining exacting API when Filter is used elsewhere. > > As an example when parsing a WFS 1.1 Query that does not include a > filter it is good to have an exact representation in the form of > Filter.NONE, our API would be incomplete if we do not have this idea > available for other to use (we would force programmers into bad > practices like using "null" to represent the absence of a Filter). > > Problem is these classes did a lot of harm in GeoTools at an learning > and implementation level: > - The double negative involved with Filter.NONE giving you all the > content, and Filter.ALL giving you none of the content > - Identity checks, if ( filter == Filter.NONE ), were used rather then > equals when optimizing datastore code. We tried to help the situtation > by allowing the implementation of Filter.NONE.equals( filter ) to verify > that a provided dynamically created Filter was actually had the same > values as Filter.NONE. > > Alternatives: > - Make it a Factory method - ie. FilterFactory.createAll(), > FilterFactory.createNone() - this would allow implementors to express > the placeholder ideas they intended while still allowing developers to > specify a factory for *everything*. It would also prevent the identity > checks. > - Filter.NULL - represent the absence of a Filter in a nice strongly > typed manner, note that phrased this way an Identity (==) check is good > idea! And that NULL.equals( object ) can happily return False each and > every time. > > So the question is why was Filter.ALL and Filter.NONE created? Probably > because those working on other specifications need to record what their > default behavior is... Something like a Query would like to use > Filter.NONE by default (give me all contents), something like a > ValidationTest would like to use Filter.ALL (fail no contents). > > Bleah, I like Filter.NULL, but in the analysis the factory methods buy > us more. Probably need to make the method FilterFactory.createNull( > boolean ) so those using the factory can record what they mean each and > every time. > > It is an open question how special the resulting Filter should be. > Behavior like Float.NaN is an option (equals would always return false), > and we could not visit such things with a FilterVisitor (as "null" is > literally out side of the specification - literally intended to mean "do > nothing"). >> I don't think so. So the question becomes Should add these constants to >> the Filter interface in geoapi as well? Or should we just implement them >> as just geoapi filters and not geotools filters. >> > I am not sure we can implement them as GeoAPI filters ... and have that > mean anything? We could stub them as the following: > - Filter.NONE becomes > <equals><literal>true</literal><literal>false</literal></equals> > - Filter.ALL = - Filter.NONE becomes > <equals><literal>true</literal><literal>true</literal></equals> > > Ideas, > 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 > > !DSPAM:1004,453bd729309811194215290! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
