www.digitalmars.com         C & C++   DMDScript  

D - D Properties

reply Cameron Zemek <grom_3 optusnet.com.au> writes:
Java convention:

public class SomeClass {
  private int someProperty;

  public int getSomeProperty() { 
    return this.someProperty; 
  }

  public void setSomeProperty(int someProperty) { 
    this.someProperty = someProperty; 
  }
}


D convention:
class SomeClass {
  private int m_someProperty;

  public int someProperty() {
    return m_someProperty;
  }

  public void someProperty(int someProperty) {
    m_someProperty = someProperty;
  }
}


Now my suggestion is, instead of using a naming convention prefix such as "m_"
(btw, what are the prefix conventions to use for D?) to use reference such as
"this". This would mean prefix for class fields would not be required and
result in slightly clearer code.

Also is there difference in behaviour for calling code that uses properties
from:

class SomeClass {
  public int someProperty;
}

int main(char[][] args) {
  SomeClass x = new SomeClass();
  x.someProperty = 100;
  printf("x=" + x.someProperty);
}

Is there any danger in implementing simple properties as public fields to
begin with, then changing to properties later on?
Feb 20 2004
next sibling parent SpookyET <not4_u hotmail.com> writes:
No, you can implement public fields if you don't need validation and later  
encapsulate them.
As for the prefix stuff, that is the reason why I advocated using  
properties and method names PascalStyle like you do in the .NET world.
I hate m_var, _var, var_.

public class SomeClass
{
	private int someProperty;
	
	public int SomeProperty()
	{
		return this.someProperty;
	}

	public int SomeProperty(int value)
	{
		return this.someProperty = value;
	}
}

C#
public class SomeClass
{
	private int someProperty;
	
	public int SomeProperty
	{
		get
		{
			return this.someProperty;
		}
		set
		{
			this.someProperty = value;	
		}
	}
}

On Sat, 21 Feb 2004 17:39:18 +1000, Cameron Zemek <grom_3 optusnet.com.au>  
wrote:

 Java convention:

 public class SomeClass {
   private int someProperty;

   public int getSomeProperty() {
     return this.someProperty;
   }

   public void setSomeProperty(int someProperty) {
     this.someProperty = someProperty;
   }
 }


 D convention:
 class SomeClass {
   private int m_someProperty;

   public int someProperty() {
     return m_someProperty;
   }

   public void someProperty(int someProperty) {
     m_someProperty = someProperty;
   }
 }


 Now my suggestion is, instead of using a naming convention prefix such  
 as "m_"
 (btw, what are the prefix conventions to use for D?) to use reference  
 such as
 "this". This would mean prefix for class fields would not be required and
 result in slightly clearer code.

 Also is there difference in behaviour for calling code that uses  
 properties
 from:

 class SomeClass {
   public int someProperty;
 }

 int main(char[][] args) {
   SomeClass x = new SomeClass();
   x.someProperty = 100;
   printf("x=" + x.someProperty);
 }

 Is there any danger in implementing simple properties as public fields to
 begin with, then changing to properties later on?

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 21 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Cameron Zemek wrote:
 (btw, what are the prefix conventions to use for D?)

I don't think there is one, and I'm not sure there ought to be. Naming conventions exist largely so that interfaces can be that much more consistent and readable. Private stuff isn't part of the interface, so it doesn't matter what you use. The Java convention has no rules at all concerning the names of local variables and argument names (to my knowledge) for this exact reason. -- andy
Feb 21 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:c181ja$1njt$1 digitaldaemon.com...
 Cameron Zemek wrote:
 (btw, what are the prefix conventions to use for D?)

I don't think there is one, and I'm not sure there ought to be. Naming conventions exist largely so that interfaces can be that much more consistent and readable. Private stuff isn't part of the interface, so it doesn't matter what you use. The Java convention has no rules at all concerning the names of local variables and argument names (to my knowledge) for this exact reason.

Hear, hear!
Feb 21 2004