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