Scope of variables

[bearophile]

Jonathan M Davis:

>That's why a lot of people typically use a different naming scheme for member variables (e.g. prepending them with _ or m_). As long as you're smart about naming, it's really not a problem.<

I too use the leading underscore. The problem with using name tags like the leading underscore is lack of enforcement from the compiler (there is only a partial enforcement: you have to use the same name and new instance attributes don't pop out of existance if you assign to a wrong attribute name by mistake, as in Python), and lack of standards. In other code you often find other wans to denote member variabiles.

In Java you mostly have classes and nested classes, in C you have global variables and local variables (and function arguments). But in D the situation is more complex, you have non-lambda inner functions too, so the normal safeties used in C maybe are not enough. Do you use non-lambda inner functions often in your code? I do. 

D is more complex and more powerful than both C and Java, so maybe it also needs more safeguards that are not needed in C and Java. You have to keep in mind that D code has new kinds of bugs (or higher frequency of some kinds of old bugs) because D has more features than C/Java.

Just trying to avoid bugs typical of C code is not enough in D! You have also to try to avoid D-specific bugs, coming from its differnces and new features.


>> I don't want that to be required though.
> Yeah. That would not be fun.

Both the @outer() and the idea by Sabalausky are fully optional. You are allowed to not use them, and removing them from code doesn't change what the code does. If library code that you are using uses them, you are not forced to use them in your code too.


>There's no need for the compiler or language to get into it any further than they already do.<

I am finding problems about the hiding of variable names, since years (I have some bug reports in bugzilla about sub-problems of this), so I presume for me there is a vague need for something better, to avoid the troubles I am finding. Such problems waste some of my time.


>Being too strict about stuff like that would get very annoying.<

I am not sure that's true. The @outer() is optional, this means you probably don't want to use if if you are writing 50 lines long programs, or if you are not using global variables and non-lambda inner functions a lot, and if even most of your functions are pure too. @outer() is meant to help debugging too, when you find a bug, you add those annotations, and I think this helps uncover some problems.

There are different kinds of programs, and different kinds of programmers, in some cases more strictness is desired. My experience tells me that sometimes more strictness avoids bugs that otherwise later make me waste far more time than being strict in the first place.

But of course, this requires a bit of self-discipline and experience. I program in Python too, but it has nonlocal/global and its situation is very different, so you can't compare it will with coding in D.

Bye,
bearophile