Comments on Wondering around: Beware of Scala’s type inference !

There are two options here, for both Java and Scal...

2009-05-08T06:52:00.000-07:00

There are two options here, for both Java and Scala:
1. You change your return type on your library, but not the dependent code, i.e. no recompile.
2. You change your return type and recompile your dependent code against the new return type.

Can we agree that for 1., both Scala and Java will throw exception at runtime?

For 2, you will get compile errors in both cases, hence my argument that Scala is no different than Java.
Scala will reinfer the type and find an unknown method call. It will complain about this at compile time.
Java is the same, except you'll first get a type error, which you then fix manually and then the unknown method call.

If you still disagree, I would urge you to actually try it out.

You're right, there are no implicits involved. Imp...

2009-05-07T09:06:00.000-07:00

You're right, there are no implicits involved. Implicit in Scala is an overloaded word, shouldn't have used this term. When you're not explicitly defining a return type (using type inference) the return type of the method signature is implicitly defined by the actual return type, nothing to do with Scala's implicits constructs.
In the example, the client uses the library return value as a Map (not as a mutable HashMap that is returned). If it would have explicitly declared val map as {val map : Map[String, String]} as you would do in Java, i.e. not relay on type inference, then there would not be any problem if the library changed the implementation from immutable to mutable. In other words, if you are not well defining the value you receive from the library at the time you receive it in the client, and you don’t recompile your client when the library change (though you don’t change your client code), then they will break on runtime.

You code example does not use implicits. It infers...

2009-05-07T06:00:00.000-07:00

You code example does not use implicits. It infers the type, which is no different than in Java where you manually enter it.
In both cases, if the library changes the type, the dependent code will fail. Same for Scala as for Java.

mmm, not sure we understand each other. When a lib...

2009-05-06T13:09:00.000-07:00

mmm, not sure we understand each other. When a library changes an implicit return type the client code does not necessarily have to change (like in the example in the post) and neither the Java or Scala compilers should fail when recompiling the client. But in this case the client compiled bytecode actually change - does not happen in Java since there are no implicits. Having the client bytecode change without the source code modified is not typical to Java code (unless you switch compilers) and as in the example, if you don't change the client binary in your runtime then it might break there.

Java will fail at build time (and runtime)S...

2009-05-06T12:37:00.000-07:00

Java will fail at build time (and runtime)Scala will fail at the same points under the same conditions. There is absolutely no difference.
Also, there's no mention of using implicits, which could lead to unexpected behavior, though not of the kind mentioned here.

Java will fail at build time (and runtime). To be ...

2009-05-06T10:28:00.000-07:00

Java will fail at build time (and runtime). To be more clear, if in Java you change the source one class it does not changes the compilation of other classes (though it could break their compilation). I don't know much about dynamic languages, but I believe the case is similar there (please correct me if I'm wrong). On the other hand, if in Scala you use implicit all around then changing one the source code of a library class does change the compilation output of the consumer class and this is the dangerous part.
In many large projects there are binary dependencies between libraries / modules, compiled versions of the modules are kept in a repository and unless you change their code they are will not be rebuilt. Lets say I wish to upgrade a version of a module v1.0 to v2.0 which is used by a client v1.0. I will build it with all the others and run some tests, and if all goes well then I assume that the module is backwards compatible and add it to the binary repository. Not the folks that build the product are taking together all the jar files and they break on runtime!
Now, this is not a big deal as itself. The bigger deal is that the module is not really backward compatible and you may not have all the sources handy to rebuild them from scratch as in the unfortunate case of using not open source library, but even if you do have the sources its a pain.

This is no different than in Java. If you change t...

2009-05-06T09:21:00.000-07:00

This is no different than in Java. If you change the return type in a third party library and attempt to run it, Java too will fail at runtime.

Right Ismael, I should have added that this and s...

2009-05-04T23:27:00.000-07:00

Right Ismael,

I should have added that this and some of my other posts are aiming using java in large code bases where you may not own all the code or be able to recompile it all (some of it may be in a maven like repository).

Hi Eishay, I agree that using explicit result typ...

2009-05-04T23:18:00.000-07:00

Hi Eishay,

I agree that using explicit result types is a good idea for public APIs.

As you say, with implicit result types, it's too easy to change the signature of the method without noticing and causing a binary incompatible change as result.

It should be noted that if the client recompiled the code, a compiler error would occur (instead of the runtime error). That is probably what you had in mind when you said:

"This issue is especially relevant for large projects that break up to binary dependent modules."