xsl-list
[Top] [All Lists]

Re: Relying on the orser of excution is harmful (Was: Re: XSL Help!!)

2002-12-06 12:40:36

"Gunther Schadow" <gunther(_at_)aurora(_dot_)regenstrief(_dot_)org> wrote in 
message
news:3DF0C44C(_dot_)7030808(_at_)aurora(_dot_)regenstrief(_dot_)org(_dot_)(_dot_)(_dot_)
Thanks for the reminder, Dimitre.


Hi Gunther,

I suppose one way of making sure extension functions are called in
a certain sequence would be to wrap them in xsl:variable/@select
statements and then make sure the variable is used in the next
call to an extension function that depends on the previous call.
Right?

OK, this is very close to the semantics of the "bind" operator of a
Monad.

However, if you have two xsl:variables one following the other, that
each references your $gizmo, there could be problems -- you cannot say
which will access $gizmo first. If these references change some Java
variable (e.g. property of an object), then overrun is possible.

One must ensure that ***all*** uses of an object from the outer world
occur after it has been initialized/modified.

I find that this is most naturally done with continuation passing style
(CPS) programming.


This works nicely with Java APIs that return the main
object even for methods that could just as well return void (and
unfortunately most of them do...)

<xsl:variable xmlns:e="java:my.Gizmo"
    name="gizmo" select="e:new()"/>

<xsl:variable xmlns:e="java:my.Gizmo"
    name="configured-gizmo" select="e:configure($gizmo, ...)"/>

<xsl:variable xmlns:e="java:my.Gizmo"
    name="energized-gizmo" select="e:energize($configured-gizmo,
...)"/>

Do you have a tip what to do if the Gizmo API is written as

    public void configure(...);

instead of

    public Gizmo configure(...);


When an action changes the world but does not return any value, it has
to be chained with other actions using the "then" Monadic operator.

One can implement a chain of "then-ned" actions by passing a list of
them to be executed sequentially, or again by CPS.

[skip]


It is also courious that while XSLT retracts much of the control
flow implications of a sequence of nodes, it still requires a
variable node to occur before that variable is referenced. It's
not unreasonable to require that for both readability and simple
processing reasons, but it might convey the wrong impression to
the casual XSLT programmer.

I guess that this was a way to prevent circular dependencies.


regards,
-Gunther




=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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



<Prev in Thread] Current Thread [Next in Thread>