H. S. Teoh:
I used to like this shadowing trick, until one day I got bit by
this typo. From then on, I acquired a distaste for this kind of
shadowing.
See:
https://d.puremagic.com/issues/show_bug.cgi?id=3878
Bye,
bearophile
On 6/29/14, 3:24 PM, Jacob Carlborg wrote:
On 2014-06-28 14:20, Ary Borenszweig wrote:
In Ruby the usage of a variable is always prefixed: `@foo` for instance
vars, `$foo` for global variable, `FOO` for constant. You can't make a
mistake. It's... perfect :-)
Oh, that's where you're wrong, ver
On 2014-06-28 14:20, Ary Borenszweig wrote:
In Ruby the usage of a variable is always prefixed: `@foo` for instance
vars, `$foo` for global variable, `FOO` for constant. You can't make a
mistake. It's... perfect :-)
Oh, that's where you're wrong, very wrong :). Take this for example:
class Fo
On Saturday, 28 June 2014 at 12:20:15 UTC, Ary Borenszweig wrote:
On 6/28/14, 6:30 AM, Jacob Carlborg wrote:
On 2014-06-28 08:19, dennis luehring wrote:
thx for the examples - never though of these problems
i personaly would just forbid any shadowing and
single-self-assign
and then having un
Am 29.06.2014 08:06, schrieb Kapps:
struct Foo {
int a;
this(this.a) { }
}
a parameter declaration with the name of the scope name??? totaly
different to everything else???
On Saturday, 28 June 2014 at 05:13:16 UTC, H. S. Teoh via
Digitalmars-d wrote:
Actually, this particular use case is very bad. It's just
inviting
typos, for example, if you mistyped "int a" as "int s", then
you get:
struct Foo {
int a;
this(int s) {
Am 28.06.2014 14:20, schrieb Ary Borenszweig:
On 6/28/14, 6:30 AM, Jacob Carlborg wrote:
On 2014-06-28 08:19, dennis luehring wrote:
thx for the examples - never though of these problems
i personaly would just forbid any shadowing and single-self-assign
and then having unique names (i use m_
On 6/28/14, 6:30 AM, Jacob Carlborg wrote:
On 2014-06-28 08:19, dennis luehring wrote:
thx for the examples - never though of these problems
i personaly would just forbid any shadowing and single-self-assign
and then having unique names (i use m_ for members and p_ for parameters
etc.) or give
Am 28.06.2014 11:30, schrieb Jacob Carlborg:
On 2014-06-28 08:19, dennis luehring wrote:
thx for the examples - never though of these problems
i personaly would just forbid any shadowing and single-self-assign
and then having unique names (i use m_ for members and p_ for parameters
etc.) or gi
On 2014-06-28 08:19, dennis luehring wrote:
thx for the examples - never though of these problems
i personaly would just forbid any shadowing and single-self-assign
and then having unique names (i use m_ for members and p_ for parameters
etc.) or give a compile error asking for this.x or .x (ma
Am 28.06.2014 07:11, schrieb H. S. Teoh via Digitalmars-d:
On Sat, Jun 28, 2014 at 06:37:08AM +0200, dennis luehring via Digitalmars-d
wrote:
Am 27.06.2014 20:09, schrieb Kapps:
[...]
>struct Foo {
> int a;
> this(int a) {
> this.a = a;
> }
>}
>
forgot that case -
On Sat, Jun 28, 2014 at 06:37:08AM +0200, dennis luehring via Digitalmars-d
wrote:
> Am 27.06.2014 20:09, schrieb Kapps:
[...]
> >struct Foo {
> > int a;
> > this(int a) {
> > this.a = a;
> > }
> >}
> >
>
> forgot that case - but i don't like how its currently handled,
Am 27.06.2014 20:09, schrieb Kapps:
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
Am 27.06.2014 10:20, schrieb dennis luehring:
I
think we hit the sweet spot at restricting shadowing detection
to local scopes.
sweet does not mean - use a better name or .x to avoid manualy
h
Am 27.06.2014 22:38, schrieb Tofu Ninja:
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
what i don't understand - why on earth should someone want to
shadow a(or better any) variable at all?
It can be useful if you are using mixins where you don't know
what is going to be in t
On Friday, 27 June 2014 at 20:40:24 UTC, Walter Bright wrote:
On 6/27/2014 1:38 PM, Tofu Ninja wrote:
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
what i don't understand - why on earth should someone want to
shadow a(or
better any) variable at all?
It can be useful if you
On 6/27/2014 1:38 PM, Tofu Ninja wrote:
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
what i don't understand - why on earth should someone want to shadow a(or
better any) variable at all?
It can be useful if you are using mixins where you don't know what is going to
be in th
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
what i don't understand - why on earth should someone want to
shadow a(or better any) variable at all?
It can be useful if you are using mixins where you don't know
what is going to be in the destination scope.
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
Am 27.06.2014 10:20, schrieb dennis luehring:
I
think we hit the sweet spot at restricting shadowing detection
to local scopes.
sweet does not mean - use a better name or .x to avoid manualy
hard to detect problems - its like di
Am 26.06.2014 02:41, schrieb Walter Bright:
On 6/25/2014 4:03 PM, bearophile wrote:
The simplest way to avoid that kind of bugs is give a "shadowing global x error"
(similar to the shadowing errors D gives with foreach and with statements). But
this breaks most existing D code.
D has scoped lo
Am 27.06.2014 10:20, schrieb dennis luehring:
I
think we hit the sweet spot at restricting shadowing detection to local scopes.
sweet does not mean - use a better name or .x to avoid manualy hard to
detect problems - its like disabled shadow detection in local scopes
what i don't understand
On 2014-06-26 02:41, Walter Bright wrote:
I suggest that your issues with global variables can be mitigated by
adopting a distinct naming convention for your globals. Frankly, I think
a global variable named "x" is execrable style - such short names should
be reserved for locals.
No need to ha
But having something enforced by the compiler is better.
I meant, it could be better.
Bye,
bearophile
Walter Bright:
I suggest that your issues with global variables can be
mitigated by adopting a distinct naming convention for your
globals. Frankly, I think a global variable named "x" is
execrable style - such short names should be reserved for
locals.
I don't use names like 'x' for the gl
On 6/25/2014 4:03 PM, bearophile wrote:
The simplest way to avoid that kind of bugs is give a "shadowing global x error"
(similar to the shadowing errors D gives with foreach and with statements). But
this breaks most existing D code.
D has scoped lookup. Taking your proposal as principle, wher
On Wed, Jun 25, 2014 at 11:03:14PM +, bearophile via Digitalmars-d wrote:
> While I try to minimize the number of module-level variables in D
> code, sometimes they are present, and sometimes I have problems (bugs)
> caused by unwanted shadowing of global names (or sometimes more
> generally, n
While I try to minimize the number of module-level variables in D
code, sometimes they are present, and sometimes I have problems
(bugs) caused by unwanted shadowing of global names (or sometimes
more generally, names from outer scopes, but this is less common):
int x = 1;
// ...
void foo() {
26 matches
Mail list logo
