On 02/14/2011 03:48 PM, Michael Kay wrote:
While this is laudable, a refactoring like this one:
<!-- old -->
<xsl:variable name="varName">
<xsl:value-of select="xpath"/>
</xsl:variable>
<!-- new -->
<xsl:variable name="varName" select"xpath"/>
isn't safe without first doing a lot of semantic analysis. I think the
preconditions for this to be correct are something like:
"all uses of $varName are dependent only its string value"
Perhaps is there some API in Saxon that would tell if XPath is likely to
produce single-value or sequence? I mean:
concat('a', //a, 'b') will definitely produce single value
//a/concat('a', ., 'b') is likely to produce sequence
The tool is implemented in XSLT+regexp, simple regexp like
"^concat\(.*\)$" might work, but generic solution would be better
It looks to me as if your tool is trying to do refactorings based purely
on local textual pattern matching. That might give good results 95% of
the time, but 95% seems inadequate to me.
That's the point -- tool is not modifying original code, but instead
writes new code to a totally different folder. Afterwards user launches
file comparison tool, performs file compare and chooses only those line
changes he likes.
I do not think 100% refactoring tool is possible. For example, if we
take Java static analysis tools, they have all the required information,
but sometimes they give false positives, even such great tools as
FindBugs. Every change FindBugs is suggesting should be carefully
reviewed manually in one-by-one mode, not all changes are ok. Same
applies for XSLT lint -- use file compare tool to display line-by-line
differences, and tons of mouse clicks to copy changed lines.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--