Thanks for the feedback; comments inline...
-- 
Jody Garnett

On Sunday, 17 April 2011 at 6:15 PM, Andrea Aime wrote: 
> Having Function return its FunctionName... makes sense, thought the name seems
> misleading... isn't that more of a FunctionDescription?
> I understand the API is already like that, just trying to get why it's called 
> a Name.
It is called a Name because that is how the ISO 19101 or 19107 handles all 
"type" information. When describing a Record each MemberName actually contains 
the key and the type information. Stupid C++ standards :(

I think the OGC just followed suite; FunctionName comes to us from part of the 
WFS GetCapabilities data structure; specifically the FilterCapabilities....

In any case, I agree the function should be able to describe itself.
> The factory changes leave me with a "huh?" moment:
> 
>  FunctionName functionName(String name, int nargs, List<String> argNames);
> 
> So this means we now have function overloading, but not the java way, based
> on attribute types, but on the argument names instead?
I don't understand? We have an internal FunctionNameImpl; but the factory only 
allows me to call functionName( String name, int args). There is no way using 
the factory to make a FunctionName that includes the list of attributes. 
> That sounds odd to me, wouldn't it be better to leave overloading aside and 
> just
> demand a unique name?
I don't understand what you mean by overloading; this is part of FilterFactory 
(not part of FunctionFactory).

> Also, what about functions that take a varying number of arguments?
The technique used to describe this currently is:

FunctionName functionName = ff.functionName("concatenate", -2, Arrays.asList( 
new String[]{"string1","string2","string3"}));
> Most process wrapping functions do, but for the sake of simpler discussion,
> what about the case of a "in" function, in(propertyName, val1, val2, ..., 
> valn),
> how would it work respect to nargs and argnames?
Sorry here is an example of that:

FunctionName inFunctionName = ff.functionName( "in", -2, Arrays.asList( new 
String[]{"value","test1","test2"}));

I agree that the handling of varying number of arguments is poor; but it is a 
bit out of scope for what I am doing now - which is simply to make what we have 
consistent and accessible.

> 
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to