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.
------------------------------------------------------------------------------
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
