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