3 ms·
“No variable shadowing” might sound great when you’re thinking about that one time someone confused you for three seconds with the addition of a new inner varia
by anderskaseorg 8y ago
“No variable shadowing” might sound great when you’re thinking about that one time someone confused you for three seconds with the addition of a new inner variable with the same name as an outer variable. But once you realize that it equally means forbidding the addition of a new outer variable with the same name as an inner variable (even though those inner variables are supposed to be implementation details)—and, as a corollary, you can never add new builtins to the language without breaking backwards compatibility—you’ll realize that most languages allow shadowing for a reason.
- vanderZwan 8y ago> you can never add new builtins to the language without breaking backwards compatibility Adding any keyword is by definition breaking backwards compatibility, so I'd say this is the correct behavior.
- kupiakos 8y agoI think you're confusing "keyword" with "reserved word". A keyword has a special meaning in certain circumstances, while a reserved word cannot be used as an identifier. In some languages, those are the same thing. For example, "goto" is a reserved word in Java, while not a keyword. Inversely, in Fortran, keywords are not reserved names, so `if if then then else else` is valid. C# has "keywords" and "contextual keywords", both categories being keywords, but only the former being reserved names. Regardless, a builtin might be referring to a function that's included as part of the base language - like make() in Golang or zip() in Python.
- vanderZwan 8y agoEh, right. But correcting for that I still hold the same view that adding new builtins should be considered breaking backwards compatibility. EDIT: Since someone has gone through the trouble of downvoting this viewpoint, I would like an explanation as to why I'm wrong here. I cannot imagine a scenario in which doing so would not likely break existing code.
- mrgriffin 8y agoIf you allow shadowing then surely the local definition of the name will take precedence over the new name introduced in the stdlib (or wherever), and thus the program will keep behaving how it did before the new builtin was introduced. I think I must be misreading you, because it sounds like you're arguing for the idea that adding new names to an API should be considered a breaking change? I'll accept that maybe reflection will catch those changes, but with that exception why would any code even notice?
- deleted 8y ago[deleted]
- elcomet 8y agoLet's say python is adding a new builtin function, like "filter". I already have a "filter" function defined in my program, so it will shadow the builtin function, and my program will still work as intended.