I guess I should attach the patch :) On Sat, Oct 1, 2011 at 7:14 PM, Justin Deoliveira <[email protected]>wrote:
> Ok, there is a patch that adds a qualified name to the FunctionName api. An > interesting part is the process filter factory that wraps process in filter > functions. There were two ways to go. Have the factory store the functions > by qualified name... or as it did before store them by a single string of > the form "ns:local". I opted for the former but there is a potentially issue > for api that calls directly the factory and not go through factory finder. > Anyways, its a rough patch at this point, so not really tied to it. > Interested in hearing thoughts and feedback. > > > On Sat, Oct 1, 2011 at 1:13 PM, Justin Deoliveira <[email protected]>wrote: > >> >> >> On Sat, Oct 1, 2011 at 12:26 AM, Jody Garnett <[email protected]>wrote: >> >>> Go for Name across the board; we also may have interpretability between >>> Functions and Process; and it would also benefit from use of the qualified >>> Name. >>> >> I agree it is cleaner... but its not an easy api change. See next comment. >> >> >>> >>> I don't think introducing Name would be much of a trouble since the >>> current Functions would just used as is; without a namespace. >>> >>> Yup, but updating the api is tricky since getName() is already taken and >> returns a single string. What I am thinking is leave Operator.getName() as a >> String. Perhaps deprecating it and changing its name to getLocalName(). Then >> in FunctionName we add a method getFunctionName() that returns Name rather >> than String. And once Operator.getName() goes through the full deprecation >> cycle we can add back in Name getName(). Messy... >> >> >>> -- >>> Jody Garnett >>> >>> On Saturday, 1 October 2011 at 3:48 AM, Justin Deoliveira wrote: >>> >>> Hi all, >>> >>> Expanding on the previous thread about extended operators. So I like the >>> idea of not rolling out a new interface and just use functions like we have, >>> basically making extended operators syntactic sugar for functions. The only >>> potential roadblock is that function names are not namespace qualified and >>> extended operator names are. So two potential options. >>> >>> 1. Update the api of FunctionName to make getName() a Name rather than >>> just a String. >>> 2. Just accept the limitation of non namespace qualified extended >>> operator names... essentially ignoring the namespace. >>> >>> Thoughts? I sort of lean toward 2 since I think it is simpler and doesn't >>> involve any api changes. And given that today function names aren't >>> qualified i imagine its an ok limitation to impose. >>> >>> -Justin >>> >>> -- >>> Justin Deoliveira >>> OpenGeo - http://opengeo.org >>> Enterprise support for open source geospatial. >>> >>> >>> ------------------------------------------------------------------------------ >>> All of the data generated in your IT infrastructure is seriously >>> valuable. >>> Why? It contains a definitive record of application performance, security >>> threats, fraudulent activity, and more. Splunk takes this data and makes >>> sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-d2dcopy2 >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> >> >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial.
function_qname.patch
Description: Binary data
------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
