Re: FunctionSignature, rev 2

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