Subject: Re: [exsl] Naming exsl:return/exsl:result (Was: Re: [xsl] Functional programming in XSLT) From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx> Date: Mon, 19 Mar 2001 21:52:29 -0700 |
> 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? Yes. The fact that exslt:result does not terminate the function is one of the reasons for my preference. If we go with arguing for XSLT congruence, exsl:result wins again because everywhere else in XSLT, flow-of-control is ultimately determined by content model, rather than imperative instruction (xsl:goto, anyone?) I certainly think the termination point for exsl:function should be defined by the content model, not the location of exsl:result. This would make the name "exsl:return" confusing, IMO. And, ixnay on the "exsl:set-result" or "exsl:fix-result". This fails in the alanogue to "xsl:variable", "xsl:param" and "xsl:key" that I already mentioned. -- Uche Ogbuji Principal Consultant uche.ogbuji@xxxxxxxxxxxxxxx +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [exsl] Naming exsl:return/exsl:, Colin Muller | Thread | Re: [exsl] Naming exsl:return/exsl:, Trevor Nash |
Re: [xsl] Functional programming in, Uche Ogbuji | Date | Re: [xsl] Is XSLT the right name?, Uche Ogbuji |
Month |