[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Assignment no, dynamic scoping si (was: Re: RE: Wishes
Hi,
On my earlier wish list for a future XSLT some interesting threads spun off. One of them is the issue of variables. Andrew Welch wrote: 2. If a variable cannot be changed after it has been assigned, why call it a variable? Ive read the reasoning behind this, and yes strictly it is a variable, but a more appropriate name would make sense. and Dimitre Novatchev responded: Lot's of languages -- e.g. any functional progaramming language or any declarative programming language. ...
I'm certainly not the genious that Dimitre is, but for all I can see, the only use right now is as a constant! When someone declares a global variable (outside of a template) that variable's value can not be reassigned, which is O.K. with me. But it can not be overridden either, except if it is in the lexical scope. So, I conclude that variable could have been named constant (still holding on to the parameter for passing along dynamic bindings.) The only use of variables I have encountered within a template are for (1) term substitutions which make a complex Xpath expression somewhat easier to read and (2) to capture result tree fragments. Again, these are nothing else than lexically scoped constants. So, why call them variables? But it would all suddenly make sense if those variables would be dynamically scoped! So, that's another wish for a future XSLT. With dynamic scoping you had an easy answer to those who ask for "how do I assign variables": you put new bindings into the Weizenbaum environment along the template call graphs, which are gone once the call graph unravels. That's the usefulness of a global symbol without the evils of side effects. That would be a hell of a useful feature. Ah the joys of LISP :-). I suppose one could construct an environment in the form of a nodeset and make all of one's own templates pass that environment on, always, whether they need it or not. That would emulate dynamic binding. However, that would make code reuse between different developers very hard, and, explain *this* to your "web developer" :-) I think the issue with modes that I have is similar. I guess what I want is mode to be such a dynamic context, such that once I switch mode in an explicit apply-templates call, all the other apply-templates in the call-graph down from there should use the same mode until overridden. This would almost get rid of the need to construct modes. regards -Gunther
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|