Subject: [exsl] Naming exsl:return/exsl:result (Was: Re: [xsl] Functional programming in XSLT) From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Fri, 16 Mar 2001 17:31:53 +0000 |
Colin Muller wrote: > Is it doing something or being something? Is it to be viewed as an > instruction to the processor to perform a return, or as a statement > that at this point we are seeing some value? If that decision is > impossible or the answer ambiguous, ummm ... avoid the issue: > "exsl:return-value" could be read as imperative by those who want > imperative and as nominal by those who want nominal :-) Dave Hartnoll wrote: > You seem to be in two minds as to whether multiple exsl:result > elements should be allowed, perhaps to build up a compound result. > If you go the way you appear to be leaning, and only allow a single > instantiation then immediate termination would also solve all the > issues about what to do when multiple result elements are > instantiated - it just won't happen! I think these bring out very good points. exsl:return would imply that the function was immediately terminated, and imply that things like: <exsl:function name="math:min"> <xsl:param name="nodes" /> <xsl:if test="not($nodes)"> <exsl:return select="-(1 div 0)" /> </xsl:if> <exsl:return select="number($nodes[not($nodes < .)])" /> </exsl:function> would work fine - if there aren't any nodes in $nodes then it should *return*, terminating the function. But having an instruction terminate processing of a template (rather than teminate the processing of the entire stylesheet) is a real change from how XSLT works. For example (this is nicked from Mike Kay off list): <xsl:function ...> <xsl:for-each select="$param"> <xsl:if test="@id='3'"> <exsl:return select="@name"/> </xsl:if> </xsl:for-each> </exsl:function> Usually a processor could go through all the nodes in $param in parallel and arrange their results in order when it's done. If we say that the exsl:return function *terminates* the function, then working through in parallel isn't an option any more - it *has* to go through them in order to find the first one. So I don't think that exsl:return should terminate the function. And personally I think that means that it shouldn't be called exsl:return or have any connotations that the function is terminated (which unhappily I think that exsl:return-value does too). I think that it will cause confusion amongst the majority who will not read the definition closely. I think we need an imperative term that doesn't imply that the function terminates. exsl:result-in, exsl:fix-result, exsl:set-result... others? Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Functional programming in, Colin Muller | Thread | Re: [exsl] Naming exsl:return/exsl:, Colin Muller |
RE: [xsl] Functional programming in, Michael Kay | Date | [xsl] RE: [exsl] Naming exsl:return, Clapham, Paul |
Month |