I think the use case here is not really a support for global variables but for
appropriately-managed global configuration. I think that’s a special case
separate from a more general (ill-advised) use of global variables.
That suggests that Mike Kay’s assertion that a global variable is just an
implicit zero-arity function is an important insight.
If a global variable is simply providing access to a static (at runtime) but
changeable (over time) configuration then it could just as easily be provided
by a function that reads the values from an external file or any other external
data source. That external configuration file could be a separate XSLT module
that holds the data if that’s the most convenient way to implement it.
But it also suggests that you are probably better served by defining the
function if you need to ensure re-usability and portability of the code, for
all the reasons we’ve given.
So I think I can continue to assert my absolutist opinion: all global variables
should be rewritten as functions or as parameters passed as needed.
Cheers,
E.
--
Eliot Kimber
http://contrext.com
From: "Graydon graydon(_at_)marost(_dot_)ca"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
Reply-To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Date: Saturday, June 19, 2021 at 7:35 PM
To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Subject: Re: [xsl] user-defined XSLT functions and stylesheet variables?
On Sun, Jun 20, 2021 at 12:11:50AM -0000, Christophe Marchand
cmarchand(_at_)oxiane(_dot_)com scripsit:
All the responses given by Eliot and Liam respect Clean Code[1] best
practises. Many principles must be respected if you expect your code may
evolve :
I think this is one of those places where the imperative best practise
and the declarative best practise aren't perfectly congruent.
If you've got a global variable that provides part of the transform
context -- the big map of what the known languages use for quotation
marks, commas, and colons, say -- I think it's quite entirely harmless
to reference that from inside a function. The testing should be looking
at the list of names in the map and making sure the expected names are
defined for each language, but presence of a transform context with
global constants -- how many of whatever to the EMU, how many points to
the inch, etc. -- is conceptually like amending the static context by
importing module functions. I don't think it's harmful to use global
variables in this way.
(It does make me hope XSLT 4 allows
<xsl:variable name="bigLookup" as="map(*)">
<xsl:map>
....
</xsl:map>
</xsl:variable>
to be declared static.)
--
Graydon Saunders | graydonish(_at_)gmail(_dot_)com
Þæs oferéode, ðisses swá mæg.
-- Deor ("That passed, so may this.")
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--