Alternative 0: Current Implementation

Not acceptable

The current implementation(s):

AbstractExpression - number() and friends

• uses constructor reflection (search for a constructor that takes a string parameter)
  
  AttributeType.parse( Object )
• is type and context aware, not effecitvely used during filter encoding

Alternative 1: Use Apache Commons ConvertUtils

Not implemented

With this approach, we simply register instances of Converter and things will be happy.

ConvertUtils is somewhat limited:

• It only allows a single converter to be registered under a class (so more then one Date format cannot be used)
• It only does parsing, not encoding

We have reports of the implementation being based on singletons and generall not being suitable.

Alternative 2: Roll our own Interface

Implemented

This approach also has the benefit of being able to wrap around ConvertUtils, or any other library that performs literal parsing, for instance java.beans.PropertyEditor. The interface might look something like:

interface ConverterFactory {
   Converter createConverter( Object source, Class target, Hints hints;
}
interface Converter {
  boolean canConvert( Object source, Class target );
  Object convert( Object source, Class target );
}

Creating an implementation based on ConvertUtils:

class CommonsConverterFactory implements ConverterFactory {
  Converter createConverter( Object source, Class target, Hints hints ) {
     return new CommonsConverter( CommonsUtils.lookup( target ) );
  }
}

And one based on PropertyEditorManager:

class CommonsConverter implements Converter {
  Converter createConverter( Object source, Class target, Hints hints ) {
     return new PropertyEditorConverter( PropertyEditorManager.findEditor( type ) );
  }
}

Questions:

When dealing with a Date object and more then one Converter is avilable how can one choose between them?

If using the extension point, the first you get. The only way to counter act this is for the client to create a factory directly, or supply some kind of hint, liks for instance a date format.

Context Push / Class Context Alternative (GeoAPI Change)

This option was implemented

Add an additional method to Expression which takes a Class parameter:

interface Expression {
  Object evaluate( Object object );
  Object evaluate( Object object, Class context );
}

The addition being the Class hint parameter, which as it states is a hint to the expression about which type of object to return.

This requires each and every expression (including all functions) to be able to type morph.

Context Pull / Value Object Alternative (GeoAPI Change)

This option not implemented

We can have the evaulate method return a Value Object (basically a value wrapper) rather then an explicit value:

interface Expression {
  Object evaluate( Object object ); // "natural value"
  Value eval( Object object );
}

We can then use Value to "unpack" the value into the type required for the context:

interface ExpressionValue {
  Object value( Class context);
  void setValue( Object );
  Object getValue();
}

This approach matches the problem in that it let's us put off typing until it is needed (the same value may be used as a "compariable, string, and interger"), but it is not very cool for those expecting a real value out of evaualte( Object ), breaking out another method is an option.

Context Pull / Lazy Value Alternative (Geotools Change)

This option incomplete

To pull this off, expressions will now behave lazily, holding onto just a String, which can be a simple value, or something more complicated like an xml fragement.

As described in http://jira.codehaus.org/browse/GEOT-602, break out an extension point.

Cannot recommend the use of a String internally, Style objects like Stroke often use both "#FFFFFF" and Color.WHITE in time critical code). Since this approach is similar, I would recommend simply making use of the above ExpressionValue interface internally for both Cache and Morph.

Context Push Code Examples

Let's start by isolating the type morphing into a single utility class for implementators:

class ExpressionValue {
    ExpressionValue( Object value );
    ExpressionValue( double value );
    ...
    Object getValue( Class type );
    void putValue( Object value );
    ...
    double doubleValue();
    void putValue( double value );
    ...
    String toLiteral(); // may produce XML fragment if complex
    String toLiteral(URI format);
}

Putting together the proposed API with ExpressionValue we have:

class Sin implements Function {
  ...
  ...
  Object evaluate( Object object ){
       return eval( object ).getValue( Double.class );
  }
  Object evaluate( Object object, Class context){
       ExpressionValue theta = new ExpressionValue( param.evaulate( object ) );
       ExpressionValue result = new ExpressionValue( Math.sin( theta.doubleValue() ) );

       return result.getValue( context );
  }
}

Tradeoffs:

• Pro: works, easy to read
• Con: no ability to support Caching
• Con: not sure class will always provide enough context, consider Date Literals perhaps additional URI hint is needed?

class Eval extends Expression {
    ExpressionValue eval( Object value );
}

class Sin implements Function, Eval {
  ...
  ...
  Object evaluate( Object object ){
       return eval( object ).getValue( Double.class );
  }
  ExpressionValue eval( Object object ){
       ExpressionValue theta = param.eval( object );
       return new ExpressionValue( Math.sin( theta.doubleValue() ) );
  }
}

Geometry Converter to JTS

Using a WKT (or WKB) Converer to allow the Evaluation Context solution to convert to JTS would let the existing Spatial Filter Implementations work out of the box with no further effort. They would "pull" the Geometry implementation into a JTS Geometry and then proceed form there.

// no new code example needed - covered by our current needs

Please note reprojection is not covered as part of this conversion "pull"; although it could be considered part of the process (our pull method simply takes a class but that can be changed).

SpatialStratagy

Letting the Geometry implementations exist at the same level as JTS (and with greater range of expression would be a good thing.

interface SpatialStratagy {
  Class forGeometryType(); // return XXXX.class
  boolean contains( Object a, Object b); // both a and b have been pulled into XXXX.class
  boolean within( Object a, Object b ); // etc...
  ...
}

Example SpatialStratagy implementation:

interface JTSSpatialStratagy {
  Class forGeometryType(){ return Geometry.class; )
  boolean contains( Object a, Object b){
       Geometry aGeom = (Geometry) a;
       Geometry aGeom = (Geometry) a;
       return aGeom.contains( bGeom );
  }
  boolean within( Object a, Object b ){
       ....
  }
  ...
}

Our implementations would need to look up a Spatial Stratagy using the factory dance as usual. A SpatialStratagy implementation for each Geometry implementation would be quick to implement and allow for optimized performance. Adding in WKB Converters would let implementations work together without data loss.

class ContainsUmberImpl implements Contains {
    ...
    public void evaualte( Obj obj, Class type){
         Object geomA = param1.evaulate( obj ); // get back some kind of Geom
         SpatialStratagy spatial = ff.aquireSpatialStratagy( geomA.getClass() );
         if( spatial == null ){ // try to JTS
            spatial = ff.aquireSpatialStratagy( Geometry.class );
            geomA = param1.evaulate( obj, Geometry.class ); // get back some kind 
         }
         Object geomB = param2.evaulate( obj, spatial.forGeometryType());
         
         return spatial.contains( geomA, geomB );
    }
    ...
}