On Sun, Oct 2, 2011 at 3:20 AM, Justin Deoliveira wrote:
> I guess I should attach the patch :)
The patch looks good to me. May use some more testing in the
backwards compatibility area.
Cheers
Andrea
--
---
Ing. Andrea Aime
GeoSolutions S.A
I guess I should attach the patch :)
On Sat, Oct 1, 2011 at 7:14 PM, Justin Deoliveira 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 th
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 o
On Sat, Oct 1, 2011 at 12:26 AM, Jody Garnett 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
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 don't think introducing Name would be much of a trouble since the current
Functions would just used as is; without a namespace.
--
Jody
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 qua
