Sorry if this has been resolved or is in the status of "agree to disagree" after being "gummed to death". <g>

Has a naming convention emerged for naming member variables and their corresponding properties? I've seen a variety of styles in the documentation, in phobos, and in other contributed library codes. I'd prefer to utilize a standard/convention in my own code, as appropriate.

If I understand the issue, the most natural naming for a "property
getter/setter" isn't allowed because of compiler name conflicts:
class Name {
  char[] first;  // compiler complains
  ...
  char[] first { return first; }
}

Other alternatives require that the member variable name and the getter/setter be different. I've seen the use of m_ ,abbreviations for the private member variable, and getFirst and setFirst.

Is there a consensus / preference that has emerged? Am I confused?

For example, for a very simple class such as Name:
#import std.stdio;

#class NameWith_M_
#{
# private:
#//  char[] first; can't use ... conflicts with property 'getter'
#  char[] m_first;
#  char[] m_last;
#
#  public:
#  this(char[] first, char[] last) {
#    m_first = first;
#    m_last  = last;
#  }
#  char[] first() { return m_first; }
#  char[] last()  { return m_last; }
#}
#
#class NameWithAbbrev
#{
# private:
#  char[] f;
#  char[] l;

#  public:
#  this(char[] first, char[] last) {
#    f = first;
#    l = last;
#  }
#  char[] first() { return f; }
#  char[] last()  { return l; }
#}

#class NameWithGetSet
#{
# private:
#  char[] first;
#  char[] last;

#  public:
#  this(char[] first, char[] last) {
#    this.first = first;
#    this.last = last;
#  }
#  char[] getFirst() { return first; }
#  char[] getLast()  { return last; }
#}

#void main()
#{
#  NameWith_M_ joe = new NameWith_M_("Joe", "Johnson");
#  writefln("Joe's first name is ", joe.first);
#
#  NameWithAbbrev jane = new NameWithAbbrev("Jane", "Jones");
#  writefln("Jane's first name is ", jane.first);

#
#  NameWithGetSet walter = new NameWithAbbrev("Walter", "Bright");
#  writefln("Walter's last name is ", walter.getLast);
#}

I would think the first priority is clarity to the "user" of the class (including the documented signatures for the class methods) , and the second is readability to the developer.

Personally, I prefer m_first to clarify that a class member variable is being used within the actual class code, and preserving the most natural naming for the user of the class.

Other thoughts appreciated.

Lynn Allan wrote:
> Sorry if this has been resolved or is in the status of "agree to
> disagree" after being "gummed to death". <g>
> 
> Has a naming convention emerged for naming member variables and their
> corresponding properties? I've seen a variety of styles in the
> documentation, in phobos, and in other contributed library codes. I'd
> prefer to utilize a standard/convention in my own code, as
> appropriate.
<snip>

If class users aren't going to manipulate the member variable, it doesn't matter that much what you call it.  But yes, a convention is useful.

Since this thread cropped up a while back

http://www.digitalmars.com/drn-bin/wwwnews?D/28791

I've pretty much taken to prefixing internal-use member variables with an underscore.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.

On Fri, 24 Dec 2004 17:21:08 +0000, Stewart Gordon wrote:
>
> 
> If class users aren't going to manipulate the member variable, it doesn't matter that much what you call it.  But yes, a convention is useful.
> 
> Since this thread cropped up a while back
> 
> http://www.digitalmars.com/drn-bin/wwwnews?D/28791
> 
> I've pretty much taken to prefixing internal-use member variables with an underscore.
> 
> Stewart.

I've never liked the m_ prefix.  It just looks ugly to me and reminds me too much of popular C++ convention. But the idea of just prefixing member variables with an underscore doesn't sound that bad.

- John R

John Reimer wrote:
> On Fri, 24 Dec 2004 17:21:08 +0000, Stewart Gordon wrote:
>  I've never liked the m_ prefix.  It just looks ugly to me and reminds me
> too much of popular C++ convention. But the idea of just prefixing
> member variables with an underscore doesn't sound that bad.
> 
> - John R
> 

I am against both using m_ as well as using _. It makes code lesser readable as code which doesn't define names as such.

I never liked the property-is-method idea, I like a more direct property approach in general (as done in .NET and, with some imagination, in JavaBeans).

I'd like the following much better:

class XYZ {
	property set char[] var {
		self = value;
	}

	property get char[] var {
		return self;
	}
}

Explanation:

property defines a programmed attribute to a class (or struct). set/get define whether a property is a set or get method. When having both enabled, the "self" member of "property set" sets the value, the "self" member of "property get" retrieves the value.

If that is not possible (which is reasonable because the language needs to undergo a big change), the pure JavaBeans idea is also good to me (using setter/getter methods).

class XYZ {
	char s[];

	void setVar(char[] s) {
		this.s = s;
	}

	char[] getVar() {
		return this.s;
	}
}

But again, it needs a change in how the language works, because this time, you need to be able to call var() on an object instantiation and this actually calls setVar(..) and/or getVar() in the class.

Regards,
Sjoerd

"Lynn Allan" <l_d_allan@adelphia.net> schrieb im Newsbeitrag news:cqhhlo$6nm$1@digitaldaemon.com...
> Has a naming convention emerged for naming member variables and their corresponding properties? I've seen a variety of styles in the documentation, in phobos, and in other contributed library codes. I'd prefer to utilize a standard/convention in my own code, as appropriate.
>
> If I understand the issue, the most natural naming for a "property
> getter/setter" isn't allowed because of compiler name conflicts:
> class Name {
>   char[] first;  // compiler complains
>   ...
>   char[] first { return first; }
> }
>
> Other alternatives require that the member variable name and the getter/setter be different. I've seen the use of m_ ,abbreviations for the private member variable, and getFirst and setFirst.

The setFirst - getFirst is commonly used in the Java world. I recommend against using this convention.

reason:
D's hides if it is a getter/setter call or direct access.
This can be of great use during debugging and refactoring.

Thomas

In article <cqi3bb$qgj$1@digitaldaemon.com>, Sjoerd van Leent says...
>
>John Reimer wrote:
>> On Fri, 24 Dec 2004 17:21:08 +0000, Stewart Gordon wrote:
>> 
>> I've never liked the m_ prefix.  It just looks ugly to me and reminds me
>> too much of popular C++ convention. But the idea of just prefixing
>> member variables with an underscore doesn't sound that bad.
>> 
>> - John R
>> 
>
>I am against both using m_ as well as using _. It makes code lesser readable as code which doesn't define names as such.
>
>I never liked the property-is-method idea, I like a more direct property approach in general (as done in .NET and, with some imagination, in JavaBeans).
>
>I'd like the following much better:
>
>class XYZ {
>	property set char[] var {
>		self = value;
>	}
>
>	property get char[] var {
>		return self;
>	}
>}
>
>Explanation:
>
>property defines a programmed attribute to a class (or struct). set/get define whether a property is a set or get method. When having both enabled, the "self" member of "property set" sets the value, the "self" member of "property get" retrieves the value.
>
>If that is not possible (which is reasonable because the language needs to undergo a big change), the pure JavaBeans idea is also good to me (using setter/getter methods).
>
>class XYZ {
>	char s[];
>
>	void setVar(char[] s) {
>		this.s = s;
>	}
>
>	char[] getVar() {
>		return this.s;
>	}
>}
>
>But again, it needs a change in how the language works, because this time, you need to be able to call var() on an object instantiation and this actually calls setVar(..) and/or getVar() in the class.
>
>Regards,
>Sjoerd


Sorry to post without research (hey, it's Christmas Eve around here).

Since a class probably has several "properties", the method names should include the propety name.

Personally I'd find it convenient if you could have a class like:

#class XYZ {
#    char[] foo;
#    property set foo(char [] v) {
#        foo = v;
#    }
#
#    property get foo() {
#        return foo;
#    }
#}

(Here, if a variable is not explicitly otherwise declared, it is private. And a property is implicitly public.)

And of course, overloading would be allowed, so I could write

#...
#property set foo(int bar, char[] v) {
#    /* do something bar with v, then */
#        foo = v;
#    }
#...

--- Just my .02€

And this would be used like

XYZ.foo = "yippee";
s = XYZ.foo;

and (for the non-default case):

XYZ.foo(3,"yippee");
s = XYZ.foo;

This could be further automated, and then I could write a class like:

#class XYZ {
#    property char[] foo;
#}

and the get and set methods would be generated -- unless I override them explicitly. So, all I'd have to write explicitly would be the non-default setter, like:

#property set foo(int bar, char[] v) {
#    /* do something bar with v, then */
#        foo = v;
#    }

georg

ps, still Christmas Eve here....

On Sat, 25 Dec 2004 02:06:10 +0000 (UTC), Georg Wrede <Georg_member@pathlink.com> wrote:

> In article <cqi3bb$qgj$1@digitaldaemon.com>, Sjoerd van Leent says...
>>
>> John Reimer wrote:
>>> On Fri, 24 Dec 2004 17:21:08 +0000, Stewart Gordon wrote:
>>>
>>> I've never liked the m_ prefix.  It just looks ugly to me and reminds me
>>> too much of popular C++ convention. But the idea of just prefixing
>>> member variables with an underscore doesn't sound that bad.
>>>
>>> - John R
>>>
>>
>> I am against both using m_ as well as using _. It makes code lesser
>> readable as code which doesn't define names as such.
>>
>> I never liked the property-is-method idea, I like a more direct property
>> approach in general (as done in .NET and, with some imagination, in
>> JavaBeans).
>>
>> I'd like the following much better:
>>
>> class XYZ {
>> 	property set char[] var {
>> 		self = value;
>> 	}
>>
>> 	property get char[] var {
>> 		return self;
>> 	}
>> }
>>
>> Explanation:
>>
>> property defines a programmed attribute to a class (or struct). set/get
>> define whether a property is a set or get method. When having both
>> enabled, the "self" member of "property set" sets the value, the "self"
>> member of "property get" retrieves the value.
>>
>> If that is not possible (which is reasonable because the language needs
>> to undergo a big change), the pure JavaBeans idea is also good to me
>> (using setter/getter methods).
>>
>> class XYZ {
>> 	char s[];
>>
>> 	void setVar(char[] s) {
>> 		this.s = s;
>> 	}
>>
>> 	char[] getVar() {
>> 		return this.s;
>> 	}
>> }
>>
>> But again, it needs a change in how the language works, because this
>> time, you need to be able to call var() on an object instantiation and
>> this actually calls setVar(..) and/or getVar() in the class.
>>
>> Regards,
>> Sjoerd
>
>
> Sorry to post without research (hey, it's Christmas Eve around here).
>
> Since a class probably has several "properties", the method names
> should include the propety name.
>
> Personally I'd find it convenient if you could have a class like:
>
> #class XYZ {
> #    char[] foo;
> #    property set foo(char [] v) {
> #        foo = v;
> #    }
> #
> #    property get foo() {
> #        return foo;
> #    }
> #}
>
> (Here, if a variable is not explicitly otherwise declared, it
> is private. And a property is implicitly public.)
>
> And of course, overloading would be allowed, so I could write
>
> #...
> #property set foo(int bar, char[] v) {
> #    /* do something bar with v, then */
> #        foo = v;
> #    }
> #...
>
> --- Just my .02€
>
> And this would be used like
>
> XYZ.foo = "yippee";
> s = XYZ.foo;
>
> and (for the non-default case):
>
> XYZ.foo(3,"yippee");
> s = XYZ.foo;
>
> This could be further automated, and then I could write a class like:
>
> #class XYZ {
> #    property char[] foo;
> #}
>
> and the get and set methods would be generated -- unless I override
> them explicitly. So, all I'd have to write explicitly would be the
> non-default setter, like:
>
> #property set foo(int bar, char[] v) {
> #    /* do something bar with v, then */
> #        foo = v;
> #    }
>
> georg
>
> ps, still Christmas Eve here....
>
>

Personely, I don't like the idea of auto get/set methods being made,
unless of course, it's only if you don't define anything. But then
why is it a property? (Think write-only var's)

I seem to remember the C# syntax for properties being a lot cleaner...
oh well. Chalk it up to bad memory. (something like
<code>
uint x
set(uint in) {x = in}
get {return x}

Foo y // read only
get {return y.bar}
</code>
but that may be too ambiguous)

Hey! Brain blast! (forgive the cheesy expression) What about non-class
properties? (For really specific typedefs)

-- 
"Unhappy Microsoft customers have a funny way of becoming Linux,
Salesforce.com and Oracle customers." - www.microsoft-watch.com:
"The Year in Review: Microsoft Opens Up"
--
"I plan on at least one critical patch every month, and I haven't been disappointed."
- Adam Hansen, manager of security at Sonnenschein Nath & Rosenthal LLP
(Quote from http://www.eweek.com/article2/0,1759,1736104,00.asp)
--
"It's been a challenge to "reteach or retrain" Web users to pay for content, said Pizey"
-Wired website: "The Incredible Shrinking Comic"

Sjoerd van Leent wrote:

> If that is not possible (which is reasonable because the language needs to undergo a big change), the pure JavaBeans idea is also good to me (using setter/getter methods).
> 
> class XYZ {
>     char s[];
> 
>     void setVar(char[] s) {
>         this.s = s;
>     }
> 
>     char[] getVar() {
>         return this.s;
>     }
> }
> 
> But again, it needs a change in how the language works, because this time, you need to be able to call var() on an object instantiation and this actually calls setVar(..) and/or getVar() in the class.

In a way it already does this - just with a different naming convention?

You can start out with a simple member field (not more than a struct):

> class Class
> {
>   int member = 0;
> }

And then if you later discover it needs more encapsulation, you can do:

> class Class
> {
>   public:
>     void member(int member) { _member = member; }
>     int member() { return _member; }
>   private:
>     int _member = 0;
> }

The beauty of this naming, as Thomas mentioned, is the simple syntax:

>   Class c = new Class();
> 
>   c.member = 42;
>   writefln("C is %d", c.member);

And that doesn't change between the simple "struct" and the full class ?
Without requiring code to be generated, or extra method call wrappers...

See also: http://www.digitalmars.com/d/cpptod.html#properties
Walter uses a "my" prefix, instead of the above underscore "_"


And like Steward Gordon said:
> If class users aren't going to manipulate the member variable,
> it doesn't matter that much what you call it.

It's more like a local variable ? (the underscore works for me)

--anders