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
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/geoapi-devel
>   


-------------------------------------------------------------------------
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

Reply via email to