Page History

...

It is true that the prior offers the code reader more information - it makes it clear the type of y is Frame, whereas in the latter code the reader only knows, from this line alone, that y is a object with x and z method/members. This is not really a significant difference; hence, we prefer the latter in performance codeThe developer writing the code knows the type is Frame, and in writing this pattern matching style, they are effectively asserting this truth, but the Scala compiler may be unable to prove this is true in many cases, particularly if object-oriented programming - base and derived classes - are involved.

Test coverage analysis can be diluted by this. For example, the assignment " val Some(c) = w " is always marked as not fully covered, possibly because the type of w is only known to be Option by the compiler, not Some. Hence,  this code actually is doing a type conversion, which as far as the Scala compiler is concerned, could fail (and throw). The programmer by writing the pattern assignment is asserting this should not be the case, but the Scala compiler cannot (or does not) prove this and so the code still has a path which throws and this path will never be exercised/covered. So the code coverage report will red-mark this line of code. This is another, albeit minor, reason to stick with the straightforward latter coding style.

Avoid scala.collections.Map. Use NonAllocatingMap (wraps Java Maps) Instead

...