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?

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/

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

"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!