- From: Bohlmann, Karsten <karsten.bohlmann@sap.com>
- Date: Mon, 15 Apr 2002 06:40:23 -0400 (EDT)
- To: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
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 08:26:00 UTC