Re: [xsl] user-defined XSLT functions and stylesheet variables?

["Joel Kalvesmaki director@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

David,

My general principle in writing a function has been to avoid any global 
parameters/variables to begin with. When it needs one or two more 
options, I supply ++-arity variants. But at some point, one might face 
the problem of function constants that must be either set in stone, or 
bound to so many function parameters the function might become confusing 
and not usable. If it cannot be simplified by breaking it up into 
smaller functions, then I either (1) reluctantly increase the arity 
options, (2) avoid the pretense of a "function" and make it part of a 
larger XSLT application, or (3) I bind those constants to global 
parameters (never global variables). (If I balk it making it a parameter 
instead of a variable, that normally means I haven't thought the problem 
through correctly -- do I really want the user control over 
such-and-such a feature?)

I am now also in the habit of always declaring @visibility. With a 
private function I might be more inclined to #1.

The question of global parameters in a user-defined function is akin to 
the use of functions within functions. If writing a function necessarily 
uses other functions (a good DRY principle), then I might be more 
inclined to #3.

In either case, I document the decisions and rationale as copiously and 
best as I can. I have found good reasons to do #1, #2, and #3. Sometimes 
problems in real-world input-output force me to repent.

Above is what I've settled on personally, but I wouldn't suggest it 
should be named best anything or another.

I would adopt Dimitre's advice and convert more functionality to inline 
XPath if that language supported templates and other unique features of 
XSLT, and if it did not elicit from me code far more crabbed and less 
maintainable than what I do in XSLT. With the XPath function 
fn:transform() I don't consider the issue important. I can (as I 
sometimes must) write an extensive 30+-parameter XSLT application 
knowing in peace it can be used in any XPath environment.

jk

On 2021-06-18 19:26, Dimitre Novatchev dnovatchev@xxxxxxxxx wrote:
> >  Is there agreement about Best Practice with respect to using
> stylesheet (global) variables inside user-defined functions?
>
> Not if one wants to have reusable functions -- many of them, in useful
> libraries that you can use again and again and that you can share with
> everyone.
>
> Best of all, define your functions as pure XPath inline functions,
> then the whole notion of something called "XSLT" is non-existent...
>
> These can be used either in pure XPath expressions, or in anything
> that uses or extends XPath, like XQuery or XSLT or ... you name it.
>
> Cheers,
> Dimitre
>
> On Fri, Jun 18, 2021 at 10:41 AM David Birnbaum djbpitt@xxxxxxxxx
> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > Dear XSLT-list,
> >
> > Is there agreement about Best Practice with respect to using
> > stylesheet (global) variables inside user-defined functions?
> >
> > If I want to be able to reuse my function in different contexts,
> > passing in everything the function needs as an explicit parameter
> > ensures that it won't have expectations about the global context.
> > There may also be philosophical reasons that functions should be
> > entirely self-contained, and should not depend on variables
> > available in the execution context.
> >
> > Meanwhile, since XSLT does not allow variables to be modified, the
> > concern (in other languages) about modifying global variables inside
> > functions does not obtain in XSLT, and my use of stylesheet
> > variables would be read-only. If I've written a one-off function
> > intended for use only in a single stylesheet, passing global
> > variables into it as explicit parameters is more verbose than
> > relying on the fact that the function, like everything else in the
> > stylesheet, has access to stylesheet variables. Passing everything
> > in explicitly does make the function more self-documenting (since
> > everything the function uses is declared as a parameter inside the
> > body) and perhaps also more convenient to test, but what do other
> > developers think about how to balance those advantages against the
> > added verbosity?

--
Joel Kalvesmaki
Director, Text Alignment Network
http://textalign.net