Comments on: Scala needs its own ecosystem http://andreasjacobsen.com/2008/10/27/scala-needs-its-own-ecosystem/ Another cause of procrastination Fri, 02 Jul 2010 06:05:30 +0000 hourly 1 http://wordpress.com/ By: Erik Engbrecht http://andreasjacobsen.com/2008/10/27/scala-needs-its-own-ecosystem/#comment-41 Erik Engbrecht Mon, 27 Oct 2008 16:06:04 +0000 http://andreasjacobsen.wordpress.com/?p=51#comment-41 I think you may be seeing a problem where there is none. A common Scala idiom is the "Pimp my library" pattern. Basically you use implicit conversions to add methods to classes. This results in a new object being created, typically one that wraps the original object, for each pimped method. This has nasty side-effects, as you can see with the RichString example. It also incurs a non-trivial performance penalty by allocating lots of little thowaway objects. I don't know exactly how he will do it, but I believe Martin is going to allow this pattern (or what this pattern achieves) without creating the temporary objects. This is good for library interoperability in general, as well as performance, not just Java interop. A better example of what you're talking about would be the compiler magic performed to make arrays look like parameterized type and be compatible with Java. A counter example would be raw types. Scala does not support raw types, even though this damages Java interop. But I agree that Scala needs its own ecosystem. I think you may be seeing a problem where there is none. A common Scala idiom is the “Pimp my library” pattern. Basically you use implicit conversions to add methods to classes. This results in a new object being created, typically one that wraps the original object, for each pimped method.

This has nasty side-effects, as you can see with the RichString example. It also incurs a non-trivial performance penalty by allocating lots of little thowaway objects. I don’t know exactly how he will do it, but I believe Martin is going to allow this pattern (or what this pattern achieves) without creating the temporary objects. This is good for library interoperability in general, as well as performance, not just Java interop.

A better example of what you’re talking about would be the compiler magic performed to make arrays look like parameterized type and be compatible with Java.

A counter example would be raw types. Scala does not support raw types, even though this damages Java interop.

But I agree that Scala needs its own ecosystem.

]]> By: Ricky Clarkson http://andreasjacobsen.com/2008/10/27/scala-needs-its-own-ecosystem/#comment-40 Ricky Clarkson Mon, 27 Oct 2008 16:04:32 +0000 http://andreasjacobsen.wordpress.com/?p=51#comment-40 Scala's == compiles down to Java's .equals, except where the resulting bytecode is comparing primitives. Java's .equals has Object as its type, therefore RichString.equals(String) is quite valid, though if RichString is sanely implemented, that will always return false (note the symmetry clause in Java's equals contract). The specific reason you might accidentally compare a RichString to a String is that you invoked an implicit conversion. If the type of == was changed so that a T could only be compared to a T or subtype of T, then the compiler would be better-placed to convert the RichString back to String. Sadly, Scala is unlikely to make large backward-incompatible changes now, so this change won't happen; or if it does the old behaviour will still be accessible via command-line switches. Scala’s == compiles down to Java’s .equals, except where the resulting bytecode is comparing primitives.

Java’s .equals has Object as its type, therefore RichString.equals(String) is quite valid, though if RichString is sanely implemented, that will always return false (note the symmetry clause in Java’s equals contract).

The specific reason you might accidentally compare a RichString to a String is that you invoked an implicit conversion. If the type of == was changed so that a T could only be compared to a T or subtype of T, then the compiler would be better-placed to convert the RichString back to String. Sadly, Scala is unlikely to make large backward-incompatible changes now, so this change won’t happen; or if it does the old behaviour will still be accessible via command-line switches.

]]>