Re: Designs for XSLT functions (Was: Re: RE: syntax su

> Hi Uche,
> 
> > > No, it doesn't. However, in languages where you otherwise have
> > > side effects (like C) you have to think extra carefully about the
> > > evaluation order.
> > 
> > My exact point is that an exsl:if function as you describe above *does* 
> > introduce an order-of-execution side effect.  That is why if an exsl:ternary 
> > is debated, I would vote that all arguments must be evaluated regardless of 
> > the value of the selector.
> 
> Well, now that you have made your own definition of the term "side effect"
> your statement holds true. However, I've never come across a defintion
> even close to yours before :-)

This is rather unfair given that the definition of the term is ever quite 
broad.

> It's crucial that the conditional operator only evaluates one of it's clauses.
> Otherwise you could not use it for recursive functions.

I see your point, but it only makes me think that exsl:if is in general otiose 
and dangerous.  I'd still advocate just sticking to xsl:if for such cases.

In particular, I would not support a use-case which had exsl:ternary() as the 
decision fulcrum of a recursive function.

> Also you would
> need that behaviour particulary when one of the claues had a side effect
> (using the more common definition :-).

It sounds as if we misunderstand each other again.  You and I apparently have 
this problem.

No great matter.  I will be supporting regular XSLT flow-of control constructs 
for exsl:function.  I suppose you'll be pushing for exsl:if().

Nothing wrong with disagreement.


-- 
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