... and then you run into fn:concat(), which, as they say in the spec, is
the "only" function that's allowed to have an arbitratry number of
arguments, to be backward compatible with XPath 1.0.
*sigh*
Should we treat fn:concat() as a special case, or allow any other builtin
function to take an unknown number of arguments? Then the mechanics of the
current "isOverloaded" (which should be renamed) would persist.
On Thu, 23 Sep 2004 finder@xxxxxxxxxxxxxxxxxxxxx wrote:
This suggestion unfortunately means re-working a number of functions that are
already implemented. Which I could do a few weeks from now, but not right
away, if this is the right direction to go in.
Luigi
On Thu, 23 Sep 2004 finder@xxxxxxxxxxxxxxxxxxxxx wrote:
I have a different idea for handling "overloaded" functions like fn:sum().
The spec "overloads" functions by changing their function signatures to
have different numbers of arguments. So it is possible to have fn:sum($a)
and fn:sum($a, $b) but fun:sum($a, $b, $c) is not specified and should not
be allowed.
I think to properly handle this, org.exist.query.Module _should_ have the
methods
FunctionSignature getSignatureForFunction(QName, numArgs)
and
Class getClassForFunction(QName, numArgs)
Change the semantics of FunctionSignature.isOverloaded() to signify that
this _QName_ is overloaded, and that AbstractInternalModules should keep
for that QName key in its Map a List of FunctionDefs (or a Map, keyed by
the number of Arguments?), not just a FunctionDef. Have two implementing
classes for fn:sum - one with one arg and one with two. Their functiondefs
could look like:
FunctionDef(SumFunction1.signature, SumFunction1.class)
FunctionDef(SumFunction2.signature, SumFunction2.class)
etc.
This takes us away from adding semantics to try to deal with "optional"
sequences as arguments, including the concept of "unlimited" sequences
(which is there now but which I now think is not right).
What do you think?
On Thu, 23 Sep 2004, Wolfgang Meier wrote:
I have been thinking a bit more about the changes you proposed. They point
into the right direction:
Currently, FunctionSignature.isOverloaded() indicates if a function may
accept
more arguments than those specified in the function signature. A typical
example is fn:sum().
However, there are also several functions that accept only one, optional
argument. In this case, the optional argument should be made explicit.
I thus propose that we
1) add another flag to SequenceType: isOptional. A predefined optional
argument is then just specified in the argument list like a required
argument.
2) rename isOverloaded to unlimitedArgs to indicate that a function may
accept
any number of arguments
You can then implement the two methods isUnlimitedArguments() and
isArgumentCountAllowed() based upon this information.
Wolfgang
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Exist-open mailing list
Exist-open@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/exist-open
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Exist-open mailing list
Exist-open@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/exist-open
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Exist-open mailing list
Exist-open@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/exist-open
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here:
http://sf.net/ppc_contest.php