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
