Re: [Geotools-devel] How to use "anonymous" OGC Filter Functions

[Gabriel R. <gr...@op...>]

Alright, thanks all for the comments.
A separate interface was my preference as well but for some reason I
thought it would bring higher hesitation. Glad it doesn't.
So, for the time being I can go with InternalFunction as a marker interface.
I don't quite see the need for a clone like method, as it's purpose is
to easily allow for anonymous inner classes to be used as function and
hence I can't think of a use case where such an object wouldn't be
immutable given there's no FilterFactory that would return a different
implementation or anything like that?

Cheers,
Gabriel

On Mon, Jul 9, 2012 at 6:00 AM, Andrea Aime
<and...@ge...> wrote:
> On Sun, Jul 8, 2012 at 9:53 PM, Gabriel Roldan <gr...@op...> wrote:
>
>> This works ok except when it comes to use SimplifyingFilterVisitor
>> down in the call chain (an hence any DuplicatingFilterVisitor
>> specialization), because visit(Function) will try to return a new
>> instance looking up the function factory by name, which does not
>> exist.
>>
>> For this reason, and in order to keep it as simple as possible, I
>> wonder if it would be ok to say that VolatileFunctions are not
>> "cloneable", and so instruct DuplicatingFilterVisitor.visit(Function,
>> Object) not to go through the SPI lookup for VolatileFunctions, but
>> return them directly.
>> Another possibility is to add a separate marker interface, but I would
>> rather avoid bloating the API.
>
> VolatileFunction javadoc says:
>
>   Marker interface indicating that that the function return value can change
>   during a single data access operation even if the argument values provided to
>   it remain constant
>
> The above has nothing to do with the function being clonable or not,
> or encodable in sql or not, it just means the function cannot be simplified out
> even if all it parameters are constants, I would avoid using it
> outside of its semantics.
>
> I see two different solutions depending on what you want to achieve.
> Is the intention to hide the function from the capabilities documents and
> from spi enumeration? If so a marker interface that hides the function from
> the enumeration but still makes it possible to create it via SPI would do.
>
> If instead the registration in SPI is not desired at all a InternalFunction
> interface like the one Jody suggested seems a good fit, and it's probably
> less risky system wide, and easier to implement.
> Would also open the door to functions that are runtime made, such
> as with bytecode generation, which in turn might make scripting
> languages integration easier.
>
> Cheers
> Andrea
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
> mob:    +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf



-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.