Re: [xsl] Re: Re: Increment/decrement a variable in XSL

[Petr Cimprich <petr at gingerall dot cz>]

You have, however, good points. My experience with those ugly 
side-effects is based on one processor only, whose internals I know in 
detail. Since funct:script/xsl:script isn't supported by common 
processors yet, the portability hasn't been a practical issue. I roll 
back my suggestion as an alternative XSLT solution, this is more likely 
a proprietary optimization outside of the area of interest of this list.

Have a nice day,
Petr


Jeni Tennison wrote:

>
>Dimitre's absolutely right. Being able to bug out to a different
>programming language can be really useful because they have support
>for things that XPath/XSLT doesn't support (e.g. regular expressions)
>or because they have access to system information that XPath doesn't
>have access to (e.g. the current date and time; file listings).
>func:script (and xsl:script in the XSLT 1.1 WD, on which it's based)
>give a standard way of referring to implementations of extension
>functions in other programming languages for these kinds of tasks.
>
>However, it's very dangerous to use extension functions or extension
>elements that have side-effects in XSLT, such as counters or
>extensions that read and update databases. This is because XSLT is
>designed around the basic assumption that you can evaluate the same
>expression multiple times without affecting the result of that or
>other expressions.
>
>Imagine you had a simple function:
>
><func:script language="javascript" implements-prefix="my">
>  var count = 0;
>  function increment() {
>    count++;
>    return count;
>  }
></func:script>
>
>And that in your XSLT you had:
>
>  <xsl:variable name="count" select="my:increment()" />
>  <xsl:value-of select="$count" />
>  <xsl:value-of select="$count + 1" />
>
>As XSLT is designed, a processor is free to evaluate the expression
>"my:increment()" once, five times, ten times, 100 times if it wants.
>Realistically, a processor might evaluate it once (to assign the
>result to $count, which is then used in the two xsl:value-of
>instructions) or it might evaluate it twice (once for each of the
>xsl:value-of instructions in which the $count variable is referenced)
>if it thinks that storing the variable is going to be more costly than
>evaluating it twice. If it did the latter, then rather than getting
>"1" and "2", you'd get "1" and "3".
>
>Equally, if you had:
>
>  <xsl:value-of select="my:increment()" />
>  <xsl:value-of select="my:increment()" />
>
>a processor is free to evaluate the function call my:increment() as
>many times as it likes. It might evaluate it twice (once for each
>xsl:value-of instruction) or it might evaluate it once (detecting that
>the same expression was used in both places and that therefore it can
>use the same value) if it thinks that storing the value is going to be
>less costly than evaluating it twice. If it does the latter, then
>rather than getting "1" and "2", you'd get "1" and "1".
>
>In other words, the assumption that nothing in XSLT produces side
>effects enables XSLT processors to make all sorts of useful
>optimisations. If you use an extension that does have side effects,
>and your processor performs these optimisations, then you will run
>into problems.
>
>Cheers,
>
>Jeni
>
>---
>Jeni Tennison
>http://www.jenitennison.com/
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>

-- 
Petr Cimprich
Ginger Alliance
www.gingerall.com




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list