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 <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 -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ 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
