- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
xml.Elem unapplySeq works on Node?
Mon, 2011-07-11, 16:27
Dear Scala friends,
We have noticed a strange bug in the xml package.
The following code gives a type error on e (saying it is a Node, not an Elem).
/////val file = xml.XML.loadFile(args(0))val siteGroups = file \\ "MyNode" //println(siteGroups)println(siteGroups.size)
import scala.xml._import scala.xml.transform._
object t extends RewriteRule { override def transform(n: Node): Seq[Node] = n match { case e@Elem(_, "MyNode", attribs, _, _*) => val newAttrs = attribs.remove("attribToDrop") e.copy(attributes = newAttribs) case other => other }}
object rt extends RuleTransformer(t)
val newFile = rt(file)
/////////
After examination, we noticed that: - Elem is not a "true" case class: its methods are implemented ad hoc - the unapplySeq method is defined not for an Elem, but for a Node?! - casting e to Elem did solve the problem Is the signature of the unapplySeq indeed the cause for the type error?Is there a particular reason for this signature? Was somebody else already bitten by this?Are there plans to make this clearer (at least for newbies)?
At least now you're warned! ;-)
Gilles.
We have noticed a strange bug in the xml package.
The following code gives a type error on e (saying it is a Node, not an Elem).
/////val file = xml.XML.loadFile(args(0))val siteGroups = file \\ "MyNode" //println(siteGroups)println(siteGroups.size)
import scala.xml._import scala.xml.transform._
object t extends RewriteRule { override def transform(n: Node): Seq[Node] = n match { case e@Elem(_, "MyNode", attribs, _, _*) => val newAttrs = attribs.remove("attribToDrop") e.copy(attributes = newAttribs) case other => other }}
object rt extends RuleTransformer(t)
val newFile = rt(file)
/////////
After examination, we noticed that: - Elem is not a "true" case class: its methods are implemented ad hoc - the unapplySeq method is defined not for an Elem, but for a Node?! - casting e to Elem did solve the problem Is the signature of the unapplySeq indeed the cause for the type error?Is there a particular reason for this signature? Was somebody else already bitten by this?Are there plans to make this clearer (at least for newbies)?
At least now you're warned! ;-)
Gilles.