We are heading into proposal territory :-( However I think you have
found a real issue with the Function api - I am sorry I did not catch it
earlier.
Here is the use code example:
interface Function {
String getName();
List getParams();
}
class FunctionImpl {
Object evaulate ( Object obj, Class context ){
String name = getName();
List<Object> params = new ArrayList<Object>();
for( Expression expr : getParams() ){
params.add( expr.evaulate( obj ), null );
}
Library library = LibraryFinder.find( name, params );
Object value = library.evaulate( name, params );
return new Value( value ).value( context );
}
}
interface Library {
FilterCapabilities getFilterCapabilities(); // definition of
library functions with name and parameters
Object evaluate( String name, List params );
}
Observations:
- I combined LibraryFactory and Library since the object is stateless.
- We should use the FilterCapabilies to force the the parameters into
the correct type
> Ok you have an interesting idea Jody, but I really need to focus here
> and not wander off on a design tangent.
Try and find easy problems them; problems with API are almost always
design related.
> How will i look up all functions available and report back their names
> and number of arguments? Code example welcome :).
for( Library library : LibraryFinder.getAll() ){
FilterCapabilities capabilities = library.getFilterCapabilities();
// informatin about function names and number of objects is in
capabilities object
}
>
> -Justin
>
> Jody Garnett wrote:
>> 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
>>>>
>>>>
>>>>
>>>
>>
>>
>> -------------------------------------------------------------------------
>>
>> 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,45c8ea8a130921425493344!
>>
>
>
-------------------------------------------------------------------------
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
