Re: [xsl] () eq () vs () = ()

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