[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tamie] What should functions do?
Here are some ideas regarding functions.
- Chuck
Functions should be functional, in the sense that they are side effect free. This means they can't modify the event board, which means they can't contain any catch or post instructions. It also means they can't start scriplets, since the scriplets may contain catch or post instructions. They may have exit (or we may call it return) instructions to allow multiple exit paths, but since they are called from Xpath expressions, the exit will never automatically "bubble up" and cause the calling scriplet or function to exit. Other eTSM instructions like var, decide, loop, eval, etc. may be used. Functions can call other functions, or call themselves recursively. They may call external code, but correct results are not guaranteed unless the external code is side-effect free.
<JD> Per last meeting, there seems to be a general agreement on all the above. The question that arises however is: given the remaining eTSM ops that can be used inside a function (var, decide, loop, eval), can we still assume that we can invoke an eTSM fn inside an XPath expr? Beacuse that will require more than XSLT functions (when implemented using XSLT): e.g. a loop requires an XSLT named template. (Now, can we still use an "XSLT fn wrapper" on top of xSLT templates?)
If we cannot use eTSM functions from inside an XPath expression, then I'd suggest we reconsider the need for distinguishing eTSM functions from eTSM scriplets, because except for the invocation context, the difference is rather thin... We would still have "external functions" (i.e. pure XSLT functions, or other lge functions, etc.)
Everything that can be done in a function can be done in a scriplet, but it may be more efficient to use a function when possible because the translation into XSLT is more straightforward. It also allows optomization, where the cached result from a previous call to the function can be used instead of executing the function again if the parameters are the same.
<JD> I see. Although again, XSLT translation may not be straightforward if using scriplets features like loops, etc. Caching previous results, may be tricky if "current time/date" sub-functions are used inside, or if the function uses global vars if any. Static analysis could alleviate this, but overall the ability to use a function inside an expression appears to be from far the most valuable argument in favor.
Now, couldn't even that (use from inside an XPath) be considered as just a convenience feature? Because we could always assign the result of the function (or effect of a scriplet) to a var, then use the var inside the expression?
Another difference is that functions are called from within Xpath expressions rather than with a dedicated eTSM instruction like "start". This means the parameters are passed by position rather than by name. Parameters are always passed explicitly. They can't be omitted, so they can't be assigned a default value in the function definition code. However, it is possible to assign the same name to multiple functions as long as they each have a different number of parameters.
Each parameter to the function and its return value should be typed. Xpath 2 has a complicated type system, but I suggest we should limit it to just a few basic ones, maybe string, number, boolean, node, and QName.
Examples:
<JD> these examples below seem to function like scriplets: the "effect" is what is implciitly returned? (no "return" or exit).
<!-- Build an XML name node -->
<etsm:function name="makename"
type="node">
<etsm:param
name="first" type="string"/>
<etsm:param name="last" type="string"/>
<etsm:param name="initials" type="string"/>
<etsm:param name="title" type="string"/>
<name>
<first><etsm:eval
expr="$first"/></first>
<last><etsm:eval
expr="$last"/></last>
<initials><etsm:eval
expr="$initials"/></initials>
<title><etsm:eval
expr="$title"/></title>
</name>
</etsm:function>
<!-- Given a name node, return a formal
representation of the name as a string -->
<etsm:function name="formalname" type="string">
<etsm:param name="name" type="node"/>
<etsm:eval expr="concat($name/title, ' ',
$name/first, ' ', $name/last)"/>
</etsm:function>
<!-- Given a name node, return a string
representation of the name starting with the last name -->
<etsm:function name="lastfirstname"
type="string">
<etsm:param
name="name" type="node"/>
<etsm:eval expr="concat($name/last, ', ', $name/first, ' ',
$name/initials)"/>
</etsm:function>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]