I agree Jody, this is a better design. But do we really need the new
interface. And I don't mean can you think of hypothetical situations in
which we could use it? I mean is there someone waiting on this issue and
will be able to commit an implementation and use it within a few weeks.
If the answer is no, I fear we are designing this for the sake of
designing it.
-Justin
Jody Garnett wrote:
> 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,45c8f4a2144911410093335!
>
--
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
