Some people’s brains just won’t bend that way; they have far too many defences against it. Cognitive dissonance (doublethink) is the barrier.

I think it’s fine for the behavior of code to depend on a value which is defined in an enclosing scope, in fact, it’s good. It makes that code configurable, which you sometimes want and need. You only run into trouble if the value is mutable, or if the variable it’s stored in is assignable (that is, non-final).

Theoretically speaking, that’s not necessarily the case. Remember that the language is statically typed, so a fair bit can actually be inferred by the compiler. The fact a wrapper object will be required for two separate calls can be determined at compile time, leaving the compiler to determine whether it should generate code to make calls to “frame” or to its implicit counterpart.

Whether or not this is true in practice is another question entirely, but it really wouldn’t surprise me if that were the case for this trivial example.

val frame = new JFrame
frame.title = “My Application”
frame.visible = true

…a wrapper is being created and discarded twice at runtime. Or at least so I assume – am I right? is this considered a problem?

– Thomas

Implicits in Scala are lexically scoped, unlike globally open classes in Ruby. I blogged about it sometime back. http://debasishg.blogspot.com/2008/02/why-i-like-scalas-lexically-scoped-open.html .. If this is of any help to you ..

Cheers.
- Debasish

Wow, well that was informative. Thanks, Daniel!

As already pointed out, the primary use of implicit *anything* in Scala is for type coercion. The reason for this as a separate language construct is to avoid the random and almost uncontrolled coercion that we have in Java and C (C has a bit more control, but it’s still difficult to deal with).

So anyway, the idea is that you mark a function as `implicit` and it will be automatically inserted as needed (I realize this has already been addressed, I’m just trying to lay the groundwork for my next point):

implicit def str2int(str: String) = str.toInt
val one: Int = “1″

The second line becomes:

val one: Int = str2int(”1″)

The unfortunate truth is that the addition of this language construct *demands* the introduction of the implicit parameters, otherwise it is no where near as useful. Remember that implicit functions are lexically scoped (just like everything else in Scala). This means that a type conversion can exist in one scope, but on in the one you really need it. We can imagine this as a problem in the following sort of scenario:

def doSomething(value: Option[Int]) = value match {
case Some(i) => i
case None => 0
}

All this does is unbind the Intfrom the Option. Now, we have already defined an implicit conversion from String to Int, but even with this conversion, we cannot do the following:

val param = Some(”123″)
doSomething(param) // ERROR!

The reason is that the conversion must be applied *inside* the doSomething, and the conversion is simply not in scope within that method (which is presumably in some other class). In fact, allowing this method to see the conversion as being in scope would break encapsulation horribly and really be some cause for concern. The solution is to use an implicit parameter:

def doSomething[T](value: Option[T])(implicit def conv2int(param: T): Int): Int =
value match {
case Some(i) => i
case None = 0
}

Now we can pass to this method an Option of *any* type which has some conversion to Int. This is far more flexible than our previous version, and just as type-safe. We have avoided breaking the scoping laws, and we still managed to make the implicit conversion available to the doSomething method. Oh, and btw, by currying the function in that way (the double-parens notation), we have ensured that the method signature has not been changed by requiring this additional parameter. As a matter of interest, we could express this using an equivalent (but more concise) syntax (note, I haven’t checked this and I don’t often use this syntax, so I might have gotten it slightly wrong):

def doSomething[Int <% T](value: Option[T]): Int

The issue you are raising has to do with implicit parameters as variables (using that term loosely, since idiomatic Scala “variables” are actually constants). e.g. the following:

implicit val name = “Daniel”
def doSomething(implicit val name: String) = name ” Spiewak”

doSomething // implicitly grabs parameter

I agree this is ugly and nasty. It’s nothing like global variables (since everything is still scoped), but it *is* bad design on the developer’s part. The truth is that this is a misuse of the language feature. It is *allowed* because variables are actually methods in disguise, and to keep the language consistent, the implicit modifier must be applicable to any method, even if it’s a variable. There are still times when this is desirable (as was pointed out, Scala’s documentation has a nice example), but in the general case, I think this should be avoided.

The good news: it is avoided! I don’t know of anyone who structures their code like this. Yes, there are implicit params from time to time, but always to satisfy my first example (passing the implicit conversion implicitly) and not to save a little typing with the variables.

Does this make a bit more sense?

Having said that, rather than just calling the feature awful for some arbitrary example of how it might be used for evil, I’d be open to using implicit parameters if it made my code more readable. I certainly wouldn’t put them in the same boat as globals, not even from a pure perspective — that a value is implicitly passed to a function doesn’t suddenly make it mutable nor does its use imply side effects.

I just don’t feel comfortable using a method whose behavior will change silently depending on what mixin I use.

So polymorphism is right out the window then? Boy, you’re a hard one to please

In all seriousness, I’m sure you could use implicit values in a way that’s completely confusing and baffling. My advice is to try not to. Anyway, the fact a feature exists doesn’t necessitate its use. Use language features where they make sense.

Oh, and I’m not a functional die-hard — just a general language geek. Honest.

The scope of the implicit doesn’t matter much, the important part is that it’s outside the method that’s using it, and that’s what is really bothering me.

I would think this should be even more of a concern for functional programmers like yourself and Tony, but you seem to be giving a puzzling free pass to Scala on that respect.

I just don’t feel comfortable using a method whose behavior will change silently depending on what mixin I use.