Why does Scala support shadow variables? [closed]

Question

I think that shadow variables are too dangerous to use them. Why does Scala support this language construct? There should be some strong reason for that, but I cant find it.

Tribunate

I've wondered about the same thing. Perhaps Odersky et al simply carried the behaviour across from Java without consideration. – Chondrule

I believe that Mr. Odersky has some motivation for decisions about any particular language construct. :) – Tribunate

:) fair enough. I guess he figured that a compiler warning would be enough. I can see that scalac takes a compiler option -Ywarn-shadowing, so presumably the IDEs also support it. – Chondrule

@amir75 Actually, everything -Y is work of Paul Phillips, and somewhat experimental in nature. If it's there, it is because it was actually useful for him, most likely. – Allier

I see that it's old, but... It's the strangest question I've read in a while. What would be the alternative? One huge global scope that gets massively polluted by every imported library? Weird variable and function names, like glDrawStuff or cvSeeStuff? – Alley

Answer 1

Just as a reminder: A variable, method, or type is said to shadow another variable, method, or type of the same name when it is declared in an inner scope, making it impossible to refer to the outer-scope entity in an unqualified way (or, sometimes, at all). Scala, just like Java, allows shadowing.

One possible reason I could see is that in Scala, it is frequent to have many nested scopes, each of which is relatively short (compared to e.g. Java or C++). Indeed, a block can start anywhere where an expression is expected, thus starting a new scope. The use of the shadowing names in the inner scopes is thus, on average, closer to their declaration and less ambiguous.

Moreover, inline closures often lead the programmer to need new variable names in a scope that is already crowded. Allowing shadowing also allows to keep using descriptive names that are sufficiently to the point, even if they are the same as al already used name, instead of inventing other weird names — like prefixing them with my, local, or (worse) _ or single-letter names…

Shadowing becomes less of a problem with good IDEs which can e.g. highlight in your source code the declaration of, and the references to, the variable under the cursor.

Just my two cents here…

Dave

Thank you for detailed response and for a reminder which I didn't provide. I've thought of variable shadowing in the closures context. You're right that some developers may use same names in closure's scope instead of giving some new ones. I guess that these developers just feel it more comfortable in usage. But isn't it a hidden threat? I agree that prefixing of short-scope variable's names doesn't look perfect. But it makes the code easier to understand in most cases (especially for Scala newbies). Correct me if I'm wrong. – Tribunate

Answer 2

I think that shadow variables are too dangerous to use them.

You are entitled to think whatever you want. However, since you have provided no data, studies or even reasons, that opinion has no value.

Why does Scala support this language construct?

Because it is useful. Programmers don't need to invent arbitrary identifier names just because some identifier in scope is already using it.

It makes wildcard imports more useful as well, as it removes the chance of a compile breaking just because a third party added a identifier you are using.

There should be some strong reason for that, but I cant find it.

Why should there be a strong reason for that? There are advantages to it, and in the absence of disadvantages (you presented none), that is enough.

EDIT

In answer to the disadvantages explained, I must say that is a special case of shadowing. Shadowing also affects everything in import, either through import statements or through nested package statements, and everything that is in the same package.

Let's see some examples:

// Not allowed, because it shadows List
import java.util._ 

class A {
    // Not allowed, because it shadows this, hashCode, equals, toString
    class B
}

That would make for a very annoying language.

Allier

Danger of shadow variables is too obvious to describe it in the initial question. BTW I have written about it in the comment to Jean-Philippe's answer (probably you haven't read it). But specially for you I will repeat. – Tribunate

When someone declares a variable in some scope and this variable has the same name as another one in the outer scope, he or she makes the code more complex. It's much harder to track the meaning of each of this variables. Here is a good quotation from the 'Programming in Scala': "Keep in mind that such code can be very confusing to readers, because variable names adopt new meanings in nested scopes. It is usually better to choose a new, meaningful variable name rather to shadow an outer variable." – Tribunate

@keykeeper Ok, I put an answer to that argument. – Allier