"clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cegeeq$13qg$1@digitaldaemon.com...
> In article <cegd35$13h1$1@digitaldaemon.com>, Deja Augustine says...
> >
> >clayasaurus wrote:
> >
> >> hello, I'm having a simple problem. Let's say I have a class
> >>
> >> class Foo
> >> {
> >> int size; // size var
> >>
> >> this(int _size) // size this will set it
> >> {
> >> size = _size; // set size to size
> >> }
> >> }
> >>
> >> the problem is that I have to _size for the function var.
> >> To me this seems messy, I could also use sizevar or some other strange name but
> >> I
> >> feel _size is the closest I could get to size.
> >>
> >> What I wouldn't mind is a standard way to declare, for member functions at
> >> least,
> >> something that would help tell it apart from the class member variables.
> >>
> >> Maybe something like this...
> >>
> >> class Foo
> >> {
> >> int size;
> >>
> >> this(int @size) // the '@' signifies it as a member function argument
> >> {
> >> size = @size; // this way you can tell member vars from function arguments
> >> }
> >>
> >> }
> >>
> >> so does anyone else think something like this would be good? is there a better solution already available?
> >>
> >>
> >
> >All I have to say, and this is with no great offense intended, is yuck.
> >  I'm not sure if this works in D, and I don't have the time to test it,
> >but you could always try:
> >
> >class Foo
> >{
> > int size; // size var
> >
> > this(int size)
> > {
> > this.size = size;
> > }
> >}
> >or just forget about it entirely.  Especially in that kind of a
> >function, it doesn't matter what you call it, all people care about is
> >that you have a class Foo that has a constructor that takes an integer
> >size.  You could call it this(int max) for all people'd care.
> >
> >Heck, you could do:
> >
> >this(int bazooka) // ctor to set the default size
> >{
> >
> >}
> >
> >if you really wanted.  I don't think it's worthy of adding a new symbol to the lexicon just to distinguish fields from locals.
> >
> >-Deja
>
> I think I'll just use the this.membervar way then. That seems to work. thx.

I think that's a serious mistake. It's far too easy to loose the "this." part sometime in its lifetime, and then you've a silent bug.

Matthew wrote:
> "clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cegeeq$13qg$1@digitaldaemon.com...
> 
>>In article <cegd35$13h1$1@digitaldaemon.com>, Deja Augustine says...
>>>Heck, you could do:
>>>
>>>this(int bazooka) // ctor to set the default size
>>>
>>>if you really wanted.  I don't think it's worthy of adding a new symbol
>>>to the lexicon just to distinguish fields from locals.
>>>
>>>-Deja
>>
>>I think I'll just use the this.membervar way then. That seems to work.
>>thx.
> 
> 
> I think that's a serious mistake. It's far too easy to loose the "this." part sometime in its lifetime, and then you've
> a silent bug.

This really is the sort of thing that can bite you later on.

What I typically do is just make the argument name a bit more descriptive:

    class Container {
        this(int initialSize) {
            size = initialSize;
        }
        private int size;
    }

 -- andy

In article <cehe8e$1h8u$1@digitaldaemon.com>,
 "C. Sauls" <ibisbasenji@yahoo.com> wrote:

> me wrote:
> > The @ doesn't read righ if you've ever done any pascal, because @x in pascal is the same as &x in C.

Ok, but there's already an address-of operator.

> Doesn't read right to anyone familiar with MOO or ColdC either, where @ is used to unbox lists.  Aka, in ColdC I'd do something like:
> 
> 	foo = [1, 2, 3, 4, 5];
> 	.bar(@foo);  // the same as doing: .bar(1, 2, 3, 4, 5)

Since one can overload bar() to take an array, do we really need this?

Just to add to the whole '@' mix:  it's also been used by various C/C++ compilers as a language extension for embedded systems. It allows the programmer to specify the address of a variable.

But maybe it will be used for something completely different in D.

In article <ceh35c$1ctn$2@digitaldaemon.com>, Matthew says...

>The worst of the lot is to have no decoration, since any reader of your code cannot immediately see what are member variables and what are local and/or module/namespace/global variables (for which s_ or g_ can be used). Furthermore, if you forget the this. in member initialisation, your code will have hidden bugs. Very poor.

This actually /is/ Hungarian notation, or at least part of it, and is specifically discouraged in the style guide.

What do other people think of this style-guide rule? Do you follow it? Disregard it? Do you think it's wise? Unwise?

I'll put my cards on the table here. Personally, I can't stand Hungarian notation. As per Walter's advice, I just say no. However, contrary to Matthew's claim, my code is not full of hidden bugs (well - not those associated with name clashes anyway). Maybe it's just what you're used to?

Arcane Jill

Arcane Jill wrote:

> In article <ceh35c$1ctn$2@digitaldaemon.com>, Matthew says...
> 
> 
>>The worst of the lot is to have no decoration, since any reader of your code cannot immediately see what are member
>>variables and what are local and/or module/namespace/global variables (for which s_ or g_ can be used). Furthermore, if
>>you forget the this. in member initialisation, your code will have hidden bugs. Very poor.
> 
> 
> This actually /is/ Hungarian notation, or at least part of it, and is
> specifically discouraged in the style guide.
> 
> What do other people think of this style-guide rule? Do you follow it? Disregard
> it? Do you think it's wise? Unwise?
> 
> I'll put my cards on the table here. Personally, I can't stand Hungarian
> notation. As per Walter's advice, I just say no. However, contrary to Matthew's
> claim, my code is not full of hidden bugs (well - not those associated with name
> clashes anyway). Maybe it's just what you're used to?
> 
> Arcane Jill
> 
> 

How do you feel about the following variable names?

    real i, j, k;

If I am right that in assuming these name will never have a real type in any of your code then I would say that goes to support your suggestion that it is what you are used to.

parabolis wrote:

> How do you feel about the following variable names?
> 
>     real i, j, k;
> 
> If I am right that in assuming these name will never have a real type in any of your code then I would say that goes to support your suggestion that it is what you are used to.

class Quaternion {
    real r;
    real i, j, k;
    ...
}

:)

 -- andy

Andy Friesen wrote:
> parabolis wrote:
> 
>> How do you feel about the following variable names?
>>
>>     real i, j, k;
>>
>> If I am right that in assuming these name will never have a real type in any of your code then I would say that goes to support your suggestion that it is what you are used to.
> 
> 
> class Quaternion {
>     real r;
>     real i, j, k;
>     ...
> }
> 
> :)
> 
>  -- andy

lol good point.

In article <cehqdb$1luj$1@digitaldaemon.com>, Andy Friesen says...
>
>Matthew wrote:
>> "clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cegeeq$13qg$1@digitaldaemon.com...
>> 
>>>In article <cegd35$13h1$1@digitaldaemon.com>, Deja Augustine says...
>>>>Heck, you could do:
>>>>
>>>>this(int bazooka) // ctor to set the default size
>>>>
>>>>if you really wanted.  I don't think it's worthy of adding a new symbol to the lexicon just to distinguish fields from locals.
>>>>
>>>>-Deja
>>>
>>>I think I'll just use the this.membervar way then. That seems to work. thx.
>> 
>> 
>> I think that's a serious mistake. It's far too easy to loose the "this." part sometime in its lifetime, and then you've a silent bug.
>
>This really is the sort of thing that can bite you later on.
>
>What I typically do is just make the argument name a bit more descriptive:
>
>     class Container {
>         this(int initialSize) {
>             size = initialSize;
>         }
>         private int size;
>     }
>
>  -- andy


Hrm. This will probably fix it. I am torn whether to use a form of hungarian notation (which is discouraged in the D style guide and means more typing, but also means that I can tell where the variables belong to), or to just use different variable names for the same type of variable (size, initsize).

To me, hungarian notation seems like a fail-safe way to do it, while the other way is more creative. But then I don't like making up two variable names for the same thing.

I think I'm leaning more towards decorating my variables so I know where they belong and avoid name clashes.

"clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cej8aa$28c0$1@digitaldaemon.com...
> In article <cehqdb$1luj$1@digitaldaemon.com>, Andy Friesen says...
> >
> >Matthew wrote:
> >> "clayasaurus" <clayasaurus_member@pathlink.com> wrote in message news:cegeeq$13qg$1@digitaldaemon.com...
> >>
> >>>In article <cegd35$13h1$1@digitaldaemon.com>, Deja Augustine says...
> >>>>Heck, you could do:
> >>>>
> >>>>this(int bazooka) // ctor to set the default size
> >>>>
> >>>>if you really wanted.  I don't think it's worthy of adding a new symbol to the lexicon just to distinguish fields from locals.
> >>>>
> >>>>-Deja
> >>>
> >>>I think I'll just use the this.membervar way then. That seems to work. thx.
> >>
> >>
> >> I think that's a serious mistake. It's far too easy to loose the "this." part sometime in its lifetime, and then
you've
> >> a silent bug.
> >
> >This really is the sort of thing that can bite you later on.
> >
> >What I typically do is just make the argument name a bit more descriptive:
> >
> >     class Container {
> >         this(int initialSize) {
> >             size = initialSize;
> >         }
> >         private int size;
> >     }
> >
> >  -- andy
>
>
> Hrm. This will probably fix it. I am torn whether to use a form of hungarian notation (which is discouraged in the D style guide and means more typing, but also means that I can tell where the variables belong to), or to just use different variable names for the same type of variable (size, initsize).

It's not Hungarian. That was about decorating with type, which is a very bad idea. This would be decorating with purpose, which is a very good idea.

>
> To me, hungarian notation seems like a fail-safe way to do it, while the other way is more creative. But then I don't like making up two variable names for the same thing.
>
> I think I'm leaning more towards decorating my variables so I know where they belong and avoid name clashes.
>
>

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ceivvq$24sp$1@digitaldaemon.com...
> In article <ceh35c$1ctn$2@digitaldaemon.com>, Matthew says...
>
> >The worst of the lot is to have no decoration, since any reader of your code cannot immediately see what are member variables and what are local and/or module/namespace/global variables (for which s_ or g_ can be used). Furthermore,
if
> >you forget the this. in member initialisation, your code will have hidden bugs. Very poor.
>
> This actually /is/ Hungarian notation, or at least part of it, and is specifically discouraged in the style guide.

This is not Hungarian. That was about decorating with type, which is a very bad idea. This would be decorating with purpose, which is a very good idea.


>
> What do other people think of this style-guide rule? Do you follow it? Disregard it? Do you think it's wise? Unwise?
>
> I'll put my cards on the table here. Personally, I can't stand Hungarian notation. As per Walter's advice, I just say no. However, contrary to Matthew's claim, my code is not full of hidden bugs (well - not those associated with name clashes anyway). Maybe it's just what you're used to?

Sigh. I made no claims about your code, because I've never seen it.

But if you have things like the following:

    class Thing
    {
        this(int value)
        {
            this.value = value;
        }

then your code will be more prone to maintenance errors than

    class Thing
    {
        this(int value)
        {
            m_value = value;
        }


If that's not obvious to you, then there's nothing more I can say.