Hmm, you seem to make the separation between interface an implementation in both your ideas, I am not sure that is the issue. I think the issue is that we are not properly modelling a function. Or at least not the parameters anyways.
Function parameters are something that will change each time the function is called. The more I think about it the more I think that they need to be mutable. Regardless, I am sorry I dont understand either of your ideas Jody :). -Justin Jody Garnett wrote: > 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 > _______________________________________________ > Geoapi-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/geoapi-devel > > !DSPAM:1004,45c8d5fa106891971556521! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
