>> Parameters shadowing outside members is pretty common and useful
> How the hell is it useful?
> If you have:
> {
> int x;
> {
> double x; // use x
> }
> }
> And you comment out or remove "double x", you've just introduced a
bug in your code
I think you missed the word *M
On 08/20/2011 08:37 PM, Timon Gehr wrote:
On 08/20/2011 08:21 PM, bearophile wrote:
Timon Gehr:
In some cases, shadowing can be handy for code generation via string
mixins (the shadowing that is disallowed, not the shadowing of globals).
Making the language more forbidding makes the generati
On 08/20/2011 08:21 PM, bearophile wrote:
Timon Gehr:
In some cases, shadowing can be handy for code generation via string
mixins (the shadowing that is disallowed, not the shadowing of globals).
Making the language more forbidding makes the generation of code simpler. But
it's simpler to wr
Timon Gehr:
> In some cases, shadowing can be handy for code generation via string
> mixins (the shadowing that is disallowed, not the shadowing of globals).
Making the language more forbidding makes the generation of code simpler. But
it's simpler to write code that generates correct code, tha
On 08/20/2011 06:54 AM, bearophile wrote:
nsf:
> > Well, D currently says I can't shadow variables:
> Right, that's a third way to shadow variables that D forbids, thank
> you. But in my post I've shown other kinds of shadowing that
> currently D accepts. Shadowing global variables has caused som
How the hell is it useful? If you have:
{
int x;
{
double x;
// use x
}
}
And you comment out or remove "double x", you've just introduced a bug
in your code.
On 8/20/2011 3:46 AM, Kagamin wrote:
Mehrdad Wrote:
Even more common with constructor parameters and instance fields.
If a naming convention encourages shadowing, it's a broken naming convention.
I don't think a convention should /encourage/ shadowing per se, but I
don't think it should discou
Mehrdad Wrote:
> Even more common with constructor parameters and instance fields.
If a naming convention encourages shadowing, it's a broken naming convention.
nsf:
> Well, D currently says I can't shadow variables:
Right, that's a third way to shadow variables that D forbids, thank you. But in
my post I've shown other kinds of shadowing that currently D accepts. Shadowing
global variables has caused some problems in my C code. One good commercial C
On Fri, 19 Aug 2011 11:07:12 -0400
bearophile wrote:
> Some ways to face this problem:
>
> 1) Do nothing.
> 2) Give optional explicit information about the source of all variable names
> used in a function, using the optional @outer() I have proposed elsewhere.
> 3) Statically disallow (gives a
On 8/19/2011 8:17 AM, Andrej Mitrovic wrote:
It's not just globals. It's hiding fields as well:
class A
{
int x;
this()
{
int x; //<- hides this.x
}
}
I've had this happen during a cut/paste session, which happens when
I'm refactoring my code.
I actually use this o
It's not just globals. It's hiding fields as well:
class A
{
int x;
this()
{
int x; // <- hides this.x
}
}
I've had this happen during a cut/paste session, which happens when
I'm refactoring my code.
After translating some buggy C code (full of gotos and global variables) to D
and going hunting for bugs for some time, I have grown a desire to write this
post.
Variable name hiding is a source of bugs. A typical example:
int x;
void foo() {
int x = 5;
// lot of code code here
x++
13 matches
Mail list logo
