XML comparison between Node and NodeSeq broken

[scabug]

Welcome to Scala version 2.8.0.RC1 (Java HotSpot(TM) Server VM, Java 1.6.0_16).
Type in expressions to have them evaluated.
Type :help for more information.

scala> val xml = <foo>bar</foo>
xml: scala.xml.Elem = <foo>bar</foo>

scala> val x2 = xml.map(i => i)
x2: scala.xml.NodeSeq = NodeSeq(<foo>bar</foo>)

scala> x2 == xml
res0: Boolean = false

scala> xml == x2
res1: Boolean = false

Old behavior:

scala> val xml = <foo>bar</foo>
xml: scala.xml.Elem = <foo>bar</foo>

scala> val x2 = xml.map(i => i)
x2: scala.xml.NodeSeq = <foo>bar</foo>

scala> x2 == xml
res0: Boolean = true

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-3334?orig=1
Reporter: David Pollak (dpp)

[scabug]

@paulp said:
"Broken" is what it was before. You left the last line off your old behavior transcript:

scala> xml == x2
res1: Boolean = false

As far as I'm concerned, if we're stuck with this idea of "universal" equality and one == method which takes an Any, then the absolute minimum requirement for the standard library is that it not be internally inconsistent. That way people who want an inconsistent equals can implement it on top of a consistent one; however there is no way to implement a consistent one on top of an inconsistent one.

As mentioned elsewhere the old behavior is still available in xml_==.

scala> x2 xml_== xml
res0: Boolean = true

scala> xml xml_== x2
res1: Boolean = false

So to the extent I have anything to say about it, this is wontfix.

[scabug]

@jorgeortiz85 said:
If we can't change "equals", perhaps we can change "map".

What if x2 was an Elem instead of a NodeSeq (similar to how str.reverse returns a String now)? That could solve this problem.

[scabug]

@eengbrec said:
This is a little more illuminating:

scala> val x1 = <foo>bar</foo>
x1: scala.xml.Elem = <foo>bar</foo>

scala> val x2 = x1.map( i => i)
x2: scala.xml.NodeSeq = NodeSeq(<foo>bar</foo>)

scala> x2.getClass
res41: java.lang.Class[_] = class scala.xml.NodeSeq$$$$anon$$1

scala> x1.getClass
res42: java.lang.Class[_] = class scala.xml.Elem

scala> x2(0)
res43: scala.xml.Node = <foo>bar</foo>

scala> x1 == x2(0)
res44: Boolean = true

scala> x2(0) == x1  
res45: Boolean = true

scala> 

So really it looks like the behavior of map has changed, not the behavior of equals.

[scabug]

@eengbrec said:
For reference: http://thread.gmane.org/gmane.comp.lang.scala.internals/2423/focus=2425

[scabug]

@paulp said:
Replying to [comment:4 eengbrec]:

So really it looks like the behavior of map has changed, not the behavior of equals.

OK, but to be clear, the behavior of equals has definitely changed. I changed it. Since NodeSeq is a Seq and therefore part of the new collections, the behavior of map has also changed.

[scabug]

@paulp said:
Replying to [comment:2 jeortiz]:

What if x2 was an Elem instead of a NodeSeq (similar to how str.reverse returns a String now)? That could solve this problem.

XMLLike? The mind reels! You know that Elem's grandparent is NodeSeq, right? Everything is a sequence in XMLtown! So nothing can be Elem "instead of" NodeSeq.

My effort at undoing the sequence damage was aborted, it was dug in too deep.

[scabug]

@lrytz said:
(In r21675) close #3338, close #3334, close #3345. review by community.

[scabug]

@lrytz said:
mistakenly closed...

[scabug]

@SethTisue said:
The scala-xml library is now community-maintained. Issues with it are now tracked at https://github.com/scala/scala-xml/issues instead of here in the Scala JIRA.

Interested community members: if you consider this issue significant, feel free to open a new issue for it on GitHub, with links in both directions.