Subject: Re: Relying on the orser of excution is harmful (Was: Re: XSL Help!!)
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Fri, 6 Dec 2002 11:40:36 -0800 (PST)
|
"Gunther Schadow" <gunther@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3DF0C44C.7030808@xxxxxxxxxxxxxxxxxxxxxxxxx
> 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
|