David,
I'm now wondering
how much I should consider avoiding conditionals in my own work.
. . . . . . . . . .
Have you found that, in general, it is best to avoid conditional
constructs? If so, could you share what advantages you have found by
doing so?
This is for you to decide, but I personally am trying to
systematically avoid XSLT conditionals and have never been sorry. The
code gets shorter and in most cases more readable. Equally significant
is the added power by using the polymorphism of <xsl:apply-templates>.
This gives us incredibly more flexibility and extensibility.
If the stylesheet module that contains the <xsl:apply-templates>
instruction is imported by different stylesheet modules, each of these
can define their own version of the templates to be selected for
execution -- in the terms of the "calculator" example, one can have
different implementations of the calculator.
Does this behavior extend to XPath's "if" statement as well, or do you
see that as a different beast? (In other words, do you find that the
advantages you obtain by avoiding XSL's conditionals do not apply as
much when considering cases that can be addressed using XPath
instead?)
I believe it is impossible to eliminate "if-expressions" in XPath
because we don't have templates there. It's a pity.
If this were possible, we could have the same advantages when
eliminating if-expressions in XPath. One could try using a HO function
to implement conditionals -- maybe I will try this.
Are there specific cases where conditional constructs should be
favored? (E.g., in <xsl:iterate> to allow Tail Call optimization?)
I haven't yet used <xsl:iterate> but from what I remember about it, I
would probably replace it, if possible, by using HOFs.
One doesn't need <xsl:if> in recursive processing. Here I recommend
not to use <xsl:call-template> for the recursive call (this *does*
require a conditional), but to use <xsl:apply-templates> with the
condition specified as predicate in the "select" attribute. This
doesn't affect any tail-recursiveness properties of the code.
As I have confessed in the past, for my work the thing I value most
about XSLT is its support of XPath. I still tend to use imperative
programming, so my scripts tend to look like the XSLT equivalent of a
Java program that uses a single class.
Based on my experience, the imperative programming style is like
following a cookbook recipe step by step -- rather boring and full of
risks.
On the other side, the declarative/functional style is more like
casting magic spells and enjoying most of the wanted work getting
magically done for you -- just because it was named.
Cheers,
Dimitre
On Sun, Mar 30, 2014 at 5:25 AM, David Rudel <fwqhgads(_at_)gmail(_dot_)com>
wrote:
On Sun, Mar 30, 2014 at 1:07 AM, Dimitre Novatchev
<dnovatchev(_at_)gmail(_dot_)com> wrote:
This is the full proof that XSLT conditional instructions can be
eliminated in any version of XSLT.
BTW, I have quite a lot of experience writing complex transformations
without any XSLT conditional instructions. :)
Cheers,
Dimitre Novatchev
Dimitre, as typical, your posts are very insightful. I'm now wondering
how much I should consider avoiding conditionals in my own work.
This provoked a general question I have for experiences XSLT
programmers who frequently use <xsl:apply-templates> or some other
method to avoid what would normally (in a more imperative regime) be
done using conditional constructions.
Have you found that, in general, it is best to avoid conditional
constructs? If so, could you share what advantages you have found by
doing so?
Does this behavior extend to XPath's "if" statement as well, or do you
see that as a different beast? (In other words, do you find that the
advantages you obtain by avoiding XSL's conditionals do not apply as
much when considering cases that can be addressed using XPath
instead?)
Are there specific cases where conditional constructs should be
favored? (E.g., in <xsl:iterate> to allow Tail Call optimization?)
As I have confessed in the past, for my work the thing I value most
about XSLT is its support of XPath. I still tend to use imperative
programming, so my scripts tend to look like the XSLT equivalent of a
Java program that uses a single class.
-David
--
"A false conclusion, once arrived at and widely accepted is not
dislodged easily, and the less it is understood, the more tenaciously
it is held." - Cantor's Law of Preservation of Ignorance.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--