- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 10 Nov 2009 11:35:53 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8253 --- Comment #4 from Greg Beauchesne <gbeauch1@jhu.edu> 2009-11-10 11:35:53 --- (In reply to comment #3) > (In reply to comment #2) > > Reclassifying this as input to XSLT 2.1. > > > > I don't have strong views on it either way. > > > > There's been a related request to allow xsl:variable to appear before xsl:sort. Yes, I saw that request and figured this one was along similar lines. > To be able to specify xsl:variable before xsl:sort is quite useful, and can > solve quite a number of new use cases. > > But specifying xsl:variable between xsl:param's doesn't look good to me. To my > thinking, that would violate the widely accepted norms of subroutine structure. Well, there are a few things, though. 1. The ability to specify xsl:variable before xsl:sort doesn't add any functional capability to the language that it didn't already have (and thus doesn't allow you to solve anything you couldn't already solve). But it, like this, allows you to follow that common rule of programming: "don't repeat yourself." XSLT, being a functional language, doesn't suffer any side effects from throwing in variables there, which makes them a nice tool for reuse in both places. 2. As demonstrated, this is already possible with xsl:param. If you want to argue from a design standpoint, it would seem to me that it's better design to reflect the intent of the programmer when possible, rather than resorting to workarounds with potentially unintended consequences. In this case, the intent is "here's a sub-expression I want to reuse" as opposed to "here's a parameter I want to allow callers to override". 3. Parameter defaults can already get pretty complicated when using the element content instead of @select, and that includes putting xsl:variable inside. (although of course that has no scope outside of the parameter default) Granted, a good editor with XML element-folding capabilities will hide this part from you, but when looking at the full XML, there's visually not much difference between this: <xsl:param name="param1"> <xsl:variable name="x" select="..." /> <xsl:variable name="y" select="..." /> ... </xsl:param> <xsl:param name="param2" select="..." /> ...and this: <xsl:param name="param1" select="..." /> <xsl:variable name="x" select="..." /> <xsl:variable name="y" select="..." /> <xsl:param name="param2" select="..." /> ----- Overall, were it not for the existence of default parameter values, I would agree with you; hence why I said in the initial request "Likewise for xsl:function if it is ever decided to allow for default parameter values there." -- there's no need without the defaults. But we have them, they are incredibly useful (especially when defining defaults in terms of other parameters), and I think this would be something that would not hurt the language. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 10 November 2009 11:35:55 UTC