From: Jody G. <jga...@re...> - 2006-10-22 22:15:35
|
Summary: - we need to account for ALL and NONE at the GeoAPI level, or ask client code to use "null" - we can create All and None interfaces and make use of a FilterFactory.createNull( boolean ) - or create All and None implementations and make them available as constants - org.opengis.filter.All - returns true for all content, equals by identity - org.opengis.filter.None - returns false for all content, equals by identity We will let implementors deal with their own problems when optimizing. Jody Cheers, Jody > 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 > _______________________________________________ > Geoapi-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geoapi-devel > |