Good idea Ben; Andrea had that suggestion earlier when looking at geometry
transformations; there is also the concept of "volitile" functions introduced
to keep "random" from being optimised away.
I would like to start a proposal page so we can capture the current
suggestions; and allow Justin to get back to work.
Justin I am under the impression you have deadline's etc associated with this
work; our policy gives you 3 days to before you can start committing (I am
never sure if that is working days or not).
--
Jody Garnett
On Monday, 2 May 2011 at 11:45 AM, Ben Caradoc-Davies wrote:
> One other thing I would like would be for functions to be able to
> advertise their inverse, if they have one, for more efficient support of
> filters.
>
> For example, a generic CQL strConcat is not readily invertible. If we
> had instead, something that in CQL was
> addPrefix('urn:x-text:MyOrg:',identifier), it could advertise its
> inverse as what in CQL would be
> removePrefix('urn:x-text:MyOrg:',identifier). I am thinking of
> translating filter queries on properties computed by a Function into
> efficient SQL queries.
>
> On 30/04/11 01:17, Justin Deoliveira wrote:
> > Hi all,
> >
> > I wanted to continue on with some chat about the FunctionName interface.
> > Jody recently modified it to return a list of argument names. However as
> > Andrea noted in that thread it does not give any information about the
> > types of those arguments.
> >
> > Well as it turns out for wfs 2.0/fes 2.0 the filter capabilities requires
> > information about argument type. I could just do something lame and stick
> > in xs:any or something like that but I figure it might be worth some
> > modifications to the interface.
> >
> > Furthermore the spec requires that a function declare its return type as
> > well. So the idea would be to modify FunctionName as follows:
> >
> > interface FunctionName {
> >
> > List<FunctionParameter> getArguments();
> >
> > FunctionParameter getReturn();
> > }
> >
> > interface FunctionParameter {
> > String getName();
> > Class getType();
> > }
> >
> > Now Andrea also brought up the issue of functions that take a variable
> > number of arguments. One possibly solution might be to add some sort of
> > flag like:
> >
> > interface FunctionName {
> > boolean hasVariableArguments();
> > }
> >
> > Or perhaps follow VolatileFunction and come with an interface called
> > VariableArgumentFunction. Such functions would return an empty argument
> > list. Or depending on if all the arguments are the same type maybe a single
> > argument. Actually following this thought maybe a flag on FunctionParameter
> > makes more sense:
> >
> > interface FunctionParameter {
> > ...
> > boolean isVariable();
> > }
> >
> >
> > Anyways thoughts?
> >
> > -Justin
> >
> >
> > --
> > Justin Deoliveira
> > OpenGeo - http://opengeo.org
> > Enterprise support for open source geospatial.
>
> --
> Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
> Software Engineering Team Leader
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
