Justin Deoliveira wrote: > Hi all, > > Transitioning from the geotools FunctionExpression to geoapi Function > has raised an issue. The FunctionExpression interface had the > "getNumArgs()" method which returns the number of arguments the function > can take. The api was also mutable which meant I could create the > function, and then set its arguments. > > However, with Function I don't have this ability. The Function interface > is immutable, which means that I cant create an instance of a function > without having the parameters that I intend to evaluate it with. The > number of arguments would then be available via getParameters().size(). >
> The underlying problem is that in a Filter capabilities document one > needs to declare which functions are available and how many arguments > they have. There is really no way to do this with this api. > Idea#1: Good conflict; should this be moved to a FunctionFactory API? Do we not need to have access to the description of the service (FunctionFactory in this case) in order to produce that filter capabilities description?; the creation of an actual Function to do the work is a separate matter. This is a tough one; since we are stuck between data representation (ie perhaps the user has an invalid function call?) and implementation (perhaps the implementation only *has* two fields to store arguments in. Idea#2: Separate as with PropertyAcccessor It strikes me we have the same scenario as with PropertyAccessor; the ability to "hold" the users request is different from the implementation used to satisfy it. 1. Make Function *pure* so we can represent what the user said 2. Make a LibraryFactory that returns FilterCapabilies information describing the function implementations made available, and makes a Library object capable of doing the work. 3. When evaluating a Function process the LibraryFactory list, grabbing the library that can implement the function the user specified, and then call that implementation Consequences: - Note this makes it easy for us to advertise the abilities of back end data sources (like Oracle) simply in terms of FilterCapabilies; in this case the "implementation" would not be provided - the function would just be written out with the SQL writer. - It would be simple to do a first cut of a Library based simply on Java reflection (using the Math class as an example) > So... any ideas on how to proceed? Should we make Function "semi > mutable", in that you can create one without specifying any parameters, > and then call #getParamters().add( ... ). I guess we would also need a > method for the number of parameters. > I am not sure this would work for someone creating a "formula builder"; what do you think of the above two ideas? Cheers, 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
