Ran up against this same issue with geoscript trying to come up with a nice
api for integrating filter functions and I like the idea of a marker
interface as well. At the time i did indeed go for implementing a full
blown factory to get around this exact problem but the solution is quite
messy since such functions truly are designed to be anonymous.
On Mon, Jul 9, 2012 at 3:00 AM, Andrea Aime <andrea.a...@geo-solutions.it>wrote:
> On Sun, Jul 8, 2012 at 9:53 PM, Gabriel Roldan <grol...@opengeo.org>
> 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
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
