W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 2002

RE: XSLT 2.0 Issue 104: Arity Overloading instead of Parameter D efaul ting for xsl:function

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Mon, 15 Apr 2002 23:31:03 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E6210602679D37@daemsg02.software-ag.de>
To: "'Bohlmann, Karsten'" <karsten.bohlmann@sap.com>, "'xsl-editors@w3.org'" <xsl-editors@w3.org>
Thanks for the comments. As you've noted in your title, this is already an
open issue,a nd I'll reference your note in the issue database so it gets
taken into account when we debate it.

Michael Kay

> -----Original Message-----
> From: Bohlmann, Karsten [mailto:karsten.bohlmann@sap.com]
> Sent: 15 April 2002 11:40
> To: 'xsl-editors@w3.org'
> Subject: XSLT 2.0 Issue 104: Arity Overloading instead of Parameter
> Defaul ting for xsl:function
> 
> 
> Hi,
> 
> I would like to bring forward an argument against optional 
> arguments for
> functions defined with xsl:function.
> 
> Optional arguments are, in my opinion, an improper transfer of the
> xsl:call-template logic. Templates have name parameters, 
> while functions
> have positional parameters. It makes perfect sense to have 
> value defaulting
> for named parameters. But for positional parameters, it's 
> rather a source of
> confusion.
> 
> It's more useful, and less error-prone, to allow overloading 
> of function
> names. In our case, overloading only concerns the arity. 
> Thus, I suggest to
> allow multiple function definitions F/n with the same name F, 
> but differing
> in the number n of formal parameters. F(e_1,...,e_n) is then 
> a static error
> if no function F/n is defined. (Or, in the spirit of XSLT 1.0 
> regulations, a
> dynamic error.)
> 
> Consequently, the default-value part of xsl:param would 
> become redundant.
> Therefore, it might be a good idea to use a different 
> sub-instruction to
> xsl:function, xsl:argument, which merely specifies the formal 
> parameter
> name.
> 
> The mechanism of default parameters can be easily simulated 
> with function
> overloading:
> 
> <xsl:function name="p:f"> <!-- 0/1-ary -->
>   <xsl:param name="x" select="42"/>
>   <xsl:return select="p:g($x)+p:h($x)"/>
> </xsl:function>
> 
> becomes
> 
> <xsl:function name="p:f"> <!-- 1-ary -->
>   <xsl:argument name="x"/>
>   <xsl:return select="p:g($x)+p:h($x)"/>
> </xsl:function>
> <xsl:function name="p:f"> <!-- 0-ary -->
>   <xsl:return select="p:f(42)"/>
> </xsl:function>
> 
> However, frequently F/n is related to F/(n+k) in a more 
> sophisticated way
> (or not at all):
> 
> <xsl:function name="p:f"> <!-- 0-ary (alternative) -->
>   <xsl:return select="if @a then p:f(@a) else p:g(@b)"/>
> </xsl:function>
> 
> Showing that overloading is more general than parameter defaulting.
> 
> 
> Best regards,
> 
> Karsten Bohlmann
> 
> Server Infrastructure Technology
> SAP AG
> 
> 
Received on Monday, 15 April 2002 17:31:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:53 GMT