app-schema has several Functions that had multiple optional arguments.
These cannot be represented with the new FunctionNameImpl.validate
restrictions. These functions were designed for ease of human use in
CQL, not for regularity to support automated discovery and dispatch. To
preserve backwards compatibility, they are now functions that take
(parameter, parameter, parameter, ...). I think Justin's design decision
is fine, and will work well in the majority of cases. The app-schema
cases are a bit irregular.
For example, from ToDirectoPostionFunction:
private static final String USAGE = "Usage:
toDirectPosition('SRS_NAME'(optional), srsName(optional), point 1, point
2(optional))";
public static final FunctionName NAME = new
FunctionNameImpl("toDirectPosition",
FunctionNameImpl.parameter("return", DirectPosition.class),
FunctionNameImpl.parameter(
"parameter", Object.class, 1, 4));
On 30/05/11 06:32, Jody Garnett wrote:
> Hmm... not sure about this one. Should we just ditch the java style
> convention for variable arguments?
> I would prefer to do this; it is up to function authors to sort out what
> arguments they need and communicate what is allowed.
--
Ben Caradoc-Davies <[email protected]>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
