Dmitri,
We've talked on this issue before, and in the main I agree with you about
the issue of side effects. This holds true in certain contexts especially
(the use of an imperative variable as an incrementer, for instance,
something that isn't as big of an issue with XSLT2 and sequences), and I
know that I work hard to educate my programmers about the dangers of dealing
with side-effect systems. The problem that comes with XSLT2 is the fact that
any access to a web service is implicitly a side-effect - the same call with
the same parameters to the same web service will potentially return
different values and moreover potentially change the state of the called
service. Ditto the notion of <xsl:document-result> with a packet of
information being sent to a web service.
In other words, a side-effect free environment can only realistically be
maintained if the system itself is completely closed, yet most of the
interesting uses of XSLT only emerge when you open up the system a bit ...
however, I liken this to a novice trying to play jazz vs. a master jazz
musician -- the master will break the rules all the time, but only because
he knows exactly why those rules exist in the first place and he weighs the
risk of breaking them as the cost of achieving art. The novice breaks them
out of ignorance, and just creates bad music, but it is the only way that
the novice will learn what those rules are in the first place.
Hey, Josh! Are you guys any closer to getting an XSLT2 engine into a public
beta? I like Saxon, but I'd love to play with XSLT2 in .NET.
Kurt Cagle
Editorial Director
Center for XML and Web Services, CUNY
----- Original Message -----
From: "Dimitre Novatchev" <dnovatchev(_at_)yahoo(_dot_)com>
To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Sent: Thursday, January 15, 2004 9:52 PM
Subject: [xsl] The real harm is in functions with side effects (Was: Re:
Using Extension Functions - Its Efficiency)
"Joshua Allen" <joshuaa(_at_)microsoft(_dot_)com> wrote in message
news:0E36FD96D96FCA4AA8E8F2D199320E52BA807D(_at_)RED-MSG-43(_dot_)redmond(_dot_)corp(_dot_)microsoft(_dot_)com(_dot_)(_dot_)(_dot_)
Well, doing so partially defeats the purpose of using XSLT, since it
means your stylesheets will not work in many other systems. It begs the
question, if you find that Java is needed, then why use XSL at all? Why
not just write the app in Java?
In any case, if you want to still use XSL and be as portable as
possible, I would recommend using the exslt templates at www.exslt.org
before giving up and writing your own extensions.
Portability is not the main issue with using extension functions.
In many cases an application is designed to work only within a certain
known
platform/environment (e.g. intranet), which is not going to change.
However, even in this case uncontrolled use of extension functions can be
dangerous. What I am referring to is that many people are not aware of the
harm that functions with side effects may cause in a functional language.
In many cases the "need" to use an extension function is due only to the
fact that the programmer comes from a procedural background and simply
does
not want to learn the functional way of programming -- and not because
there
is no way to do this without extension functions.
Due to this reason some nice-looking proposals for new extension functions
(which happen to have side effects) have not been accepted by the
management
of the EXSLT.org group.
We need to have a special section in the XSLT FAQ about extension
functions
and why functions with side effects are generally harmful in a functional
language.
Dimitre Novatchev.
FXSL developer,
http://fxsl.sourceforge.net/ -- the home of FXSL
Resume: http://fxsl.sf.net/DNovatchev/Resume/Res.html
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list