Re: [Geotools-devel] On the upgrade to geoapi Filter

[Jody G. <jga...@re...>]

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