• Cameron Zemek (36/36) Feb 20 2004 Java convention:
• SpookyET (39/78) Feb 21 2004 No, you can implement public fields if you don't need validation and lat...
• Andy Friesen (8/9) Feb 21 2004 I don't think there is one, and I'm not sure there ought to be. Naming
• Matthew (3/11) Feb 21 2004 Hear, hear!

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?

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;
	}
}


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/

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

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