I think you hit the nail on the head ... we are talking about different things :-)
Indeed I think I am onto something and a lot of the reason we are having problems of this nature is due to a design mistake we made. Let me outline Idea #2 and see if it makes sense (for get your problem for a moment and think on what "Function" is for) Function - interface matching Filter 1.1, represents "name", and some parameters as specified by the user FunctionImpl - direct implementation of the above, able to store the "name" and "parameters" (Nowhere am I talking about Cosine extends Function able to store "cos" and two parameters) This is *it* - a definition of what Function needs to do for us at the GeoAPI level to capture Filter 1.1. We do however have this idea where we would like to evaulate( Object ) a Function can get a value back, to do that we need to go from Function to an implementation (we need to look up "cos" and use our two parameters to get a value). If you remember for our implementation of PropertyAcessor we had *one* implementation that only knew how to work with Features. We broke this assumption and made our implementation of evaulate look up "propertyaccessors" that had implementations for Feature, POJOs, etc... I think we have the same situation going on here; and I can capture it in a single question: - Can we (in GeoTools) parse a Filter document that uses a function for which we have no matching implementation? To continue; the information you wanted to know (the number of parameters) is documented in the FilterCapabilities; it should *not* be modeled as part of the Function. Separation between data and metadata. Jody > 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! >> > > ------------------------------------------------------------------------- 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
