Pattern Matching against `scala.scalajs.js.Dynamic`

Question
1

Dear all,

I am following Li Haoyi’s Hands-on Tutorial. I get this warning

[warn] C:.…\Weather1.scala:57: non-variable type argument scala.scalajs.js.Dynamic in type pattern scala.scalajs.js.Array[scala.scalajs.js.Dynamic] is unchecked since it is eliminated by erasure

regarding this code

I tried to see whether one can ever get to the case _ => branch. And, it looks like there is no way! The warning makes me think the case jsonlist: js.Array[js.Dynamic] => branch always wins. So, I wonder how people do pattern matching against scala.scalajs.js.Dynamic in action? What if there is more than one important branch for two different types?

TIA,
–Hossein

2

The warning you get is not specific to js.Dynamic (or Scala.js, for that matter). It tells you that your

case jsonlist: js.Array[js.Dynamic] =>

is basically equivalent to

case jsonlist: js.Array[_] =>

In other words, the branch will be taken every time that the result of parse is a js.Array, no matter what’s inside the array. The compiler will “trust” you on the fact that the array contains only things that are js.Dynamic, but it warns about it to let you know that something might not work the way you expect.

Now of course everything is a js.Dynamic, so that’s never a problem in this case. But the Scala typecheck doesn’t know that, because it does not know the specifics of Scala.js. So you might argue that it’s fine to ignore the warning. But warnings are annoying, so here is a way that lets you silence it:

case jsonlist: js.Array[_] =>
  output.innerHTML = ""
  showResult(jsonlist.asInstanceOf[js.Array[js.Dynamic]], query)
3

Here’s a less verbose way to turn the warning off:

case jsonlist: js.Array[js.Dynamic] @unchecked =>
1 Like
4

Thank you Sebestian (?) for the explanation on the reason why I get the warning.

I guess what I’m trying to figure out is whether the .list method does ever return anything other than a js.Array[_]? In other words, will the other branch, i.e.,

ever be taken? I have tried to make that happen. And, to my surprise, it never did. I wonder what I am missing… :-?

5

Oh, yes, that’s much less unsightly. But, I still get a deprecation warning. When I do sbt -deprecation, I get:

[warn] The - command is deprecated in favor of onFailure and will be removed in 0.14.0

I see the warning speaks about - (hyphen) rather than _ (underline). I wonder that relates to then? And, has the @unchecked really managed to calm the compiler down?

6

Unfortunately the message you get is misleading, -deprecation is an option for the Scala compiler, not for sbt. See https://stackoverflow.com/questions/9578521/scala-sbt-how-to-re-run-with-deprecation (and notice that 20,000 people have had the same problem that could be easily fixed if someone simply made sbt print a better message)

7

I see. And, thanks for the link.