Subject: Re: [xsl] () eq () vs () = () From: Stefan Krause <stf@xxxxxxxx> Date: Fri, 30 Sep 2011 11:54:05 +0200 |
To make the confusion complete, deep-equals((),()) returns true(), which is IMHO the most expected behavior. Stefan Am 30.09.2011 um 11:43 schrieb Andrew Welch <andrew.j.welch@xxxxxxxxx>: > I've recently found out (over on the saxon list) that: > > () eq () > > returns the empty sequence, but > > () = () > > returns false. > > What is the benefit of returning the empty sequence over false... when > would I want that? It seems like an unecessary gotcha to me... > similar to xs:boolean('0') vs fn:boolean('0') > > Also, this is from the xpath 2.0 spec: > > "Consider the expression //part[color eq "Red"]. An implementation > might choose to rewrite this expression as //part[color = "Red"][color > eq "Red"]. The implementation might then process the expression as > follows: First process the "=" predicate by probing an index on parts > by color to quickly find all the parts that have a Red color; then > process the "eq" predicate by checking each of these parts to make > sure it has only a single color" > > ...which makes me wonder bother with using 'eq' at all. I wouldn't > use it to ensure there is only one of something, that would be done > elsewhere... I always thought it allowed the comparison to be > optimised behind the scenes, but that suggests otherwise. > > > thanks > -- > Andrew Welch > http://andrewjwelch.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] () eq () vs () = (), Andrew Welch | Thread | Re: [xsl] () eq () vs () = (), Andrew Welch |
[xsl] () eq () vs () = (), Andrew Welch | Date | Re: [xsl] () eq () vs () = (), Andrew Welch |
Month |