Andrea Aime wrote:
> Hi,
> so following up from last week discussion, it
> seems there is currently no supported way to know
> what the arguments of a function are, you are
> supposed to know before hand (Jody mentioned
> the FunctionFinder, but that does not provide
> any argument lookup method).
>
> So it seems that to get unstuck I will have to
> make a change proposal affecting both GeoTools
> and GeoApi.
>
> In particular, I'm thinking to propose something
> along these lines:
> - register a factory for the functions, not the
> functions themselves
>
cool.
Aside: There is an option we have not talked about yet - we are used to
having the factory directly make the functions. The alternative is to do
our own thing (much like we did for property access). There is no
requirement to have many Function implementations around; only that the
FilterFactory create a Function that will do something when evaulate is
called - ie it could look up the right entry in your factory and execute it.
> - a factory can create multiple functions and
> provide metadata about them (the number of
> arguments and the return type, -1 if the
> number of arguments cannot be determined
> beforehand)
>
cool - if the factory could create:
-
http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/filter/expression/Function.html
-
http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/filter/capability/FunctionName.html
Then we can use it behind a FilterFactory that supports a
getFilterCapabilities() method.
> - for most of the existing functions implementing
> FunctionExpression, we can just create a factory
> that looks up the functions, and grabs the
> metadata using the FunctionExpression interface
> (which we could un-deprecate if we make it stop
> extending org.geotools.filter.Expression)
>
You will find a few functions that I have implemented using no
deprecated code; I generally implement the XXXXFunction; and have an
internal class XXXXFunction.Name that extends FunctionName.
> - for the few others (if any) a new factory will be created
>
> This would solve the lookup issue at the GeoTools
> level. At the GeoApi level things are a bit more
> complicated because the function lookup support
> has been mutilated quite a bit.
> We should at least:
> - add back FilterCapabilities to FilterFactory
>
:-)
> - add getFunctions to FilterCapabilities,
> which in turn provides the getFunctionNames
> and getFunctionName methods
>
That is already there in some form; you can find the FunctionNames in
the FilterCapabilities data structure.
> - decide if FunctionName interface is good for
> us, or not. At the moment we do have the following:
>
> public interface FunctionName extends Operator {
> /**
> * Number of arguments the function accepts.
> */
> int getArgumentCount();
>
> /**
> * Argument names for documentation purposes if known.
> List<String> getArgumentNames();
> }
>
It is is intended to be good for us; I added getArgumentNames() in order
to be good for us; if we need something more then we should add it. The
only thing I know I was worried about was handling variable length
functions ... I currently handle it by documenting the minimum by
getArgumentCount(); and having more argumentNames() that document arg0,
arg1, etc...
> Hum, no types?
Filter is kind of type less; you could add it if you want - but then you
are almost at the Operation API.
> Oh well, I could go for that. Going into all the function implementations and
> adding the name metadata can be somewhat painful, but as a stop gap
> measure we could just name them "arg1", "arg2", ... in FunctionExpressionImpl.
>
> Opinions?
This is a great direction you are going in Andrea - very exciting.
Jody
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
