Hi,

I'm new to D and looking at the spec, I hate the idea of the gettors/settors property. Has anyone ever tried maintaining a large code base with this idea? I have! I currently work at a company that has accessors written similar this in C++ everywhere:

class FOO {
public:
int property() const { return myProperty; }
int &property()      { return myProperty; }
private:
int myProperty;
};

This effectively lets you do stuff like this:
FOO f;
int i = f.property();
f.property() = i;

It is absolutely hell to trace through code like this in a large codebase when you want to find where a member variable is ever used but not assigned. This is often done in sweeps to ensure that a particular property is used properly or to find out how it is used.

In this type of system, the only way to search for this is to look for the pattern "property()". However, good luck trying to find what you want if there's a like a 1000 references that use the property but only a few cases where it is ever externally assigned. It is a huge pain. The problem compounds itself when you have to look for a common property name. Even if you were just trying to find all instances for when the property is assigned requires doing a grep for "\<property()[ \t]*=\>" and that's when you remember how to do it properly. At least with get/set methods you can grep for getProperty() and setProperty() separately and easily.

I really hope the designers of D reconsider this aspect of the language.

Regards,
-Edward

Edward Lam wrote:
> I'm new to D and looking at the spec, I hate the idea of the gettors/settors
> property. Has anyone ever tried maintaining a large code base with this idea? I
> have! I currently work at a company that has accessors written similar this in
> C++ everywhere:
> 
> class FOO {
> public:
> int property() const { return myProperty; }
> int &property()      { return myProperty; }
> private:
> int myProperty;
> };
> 
> This effectively lets you do stuff like this:
> FOO f;
> int i = f.property();
> f.property() = i;
> 
> It is absolutely hell to trace through code like this in a large codebase when
> you want to find where a member variable is ever used but not assigned. This is
> often done in sweeps to ensure that a particular property is used properly or to
> find out how it is used.

If you use MSVC, how do the source browsing utilities fail you here?  If not MSVC, how could an IDE help automate this search?

In article <avs69v$2pt8$1@digitaldaemon.com>, Edward Lam says...

> I currently work at a company that has accessors written similar this in
>C++ everywhere:
>
>class FOO {
>public:
>int property() const { return myProperty; }
>int &property()      { return myProperty; }
>private:
>int myProperty;
>};
>
>This effectively lets you do stuff like this:
>FOO f;
>int i = f.property();
>f.property() = i;

I don't actually agree with OO, but <Niall shudders violently>

>It is absolutely hell to trace through code like this in a large codebase when you want to find where a member variable is ever used but not assigned. This is often done in sweeps to ensure that a particular property is used properly or to find out how it is used.

Good god ...

> At
>least with get/set methods you can grep for getProperty() and setProperty()
>separately and easily.
>
>I really hope the designers of D reconsider this aspect of the language.

I think it's better form to use .attribute() for read-only and .setAttribute() for writing. If you do like your company and return a writeable reference, you might as well just make the variable public will all the nastiness you mentioned. BTW, good C++ sets ALL variables in a class to zero in its constructor - you can always remove them later if speed is an issue.

My own view on properties is that yes, they are absolutely needed - for class designers and dynamically loaded libraries especially. However, I'd add the following idiom:

class X
{
public:
int foo;
};

a=X.foo(); // Read
X.foo()=5; // Error: idiom is not for writing!
X.foo=5;   // Still works, but should never be used except in 0.001% of cases

My reasoning for this is often I have to do the following in my C++:

class Y
{
int myfoo;
public:
int foo() const { return myfoo; }
// Optional Y &setFoo(int a) { myfoo=a; return *this; }
};

In other words, I want variable access via a method so I can replace it with something more complex later without breaking anything. However, to make good C++ I am forced to write lots of extra code (C++'s major failing IMHO) such as prefixing all my "properties" with "my" so they don't conflict with the read method.

My suggested idiom won't break any existing code and shortcuts the process
nicely. I'm opposed to having .getFoo() simply because (a) more typing (b) looks
ugly (c) isn't intuitively OO (properties of a real life object are a given ie;
immediately obvious - you don't "get" them. You do however set them).

Cheers,
Niall

In article <avs69v$2pt8$1@digitaldaemon.com>, Edward_member@pathlink.com says...
> I'm new to D and looking at the spec, I hate the idea of the gettors/settors property. Has anyone ever tried maintaining a large code base with this idea? I have! I currently work at a company that has accessors written similar this in C++ everywhere:
> 
> class FOO {
> public:
> int property() const { return myProperty; }
> int &property()      { return myProperty; }
> private:
> int myProperty;
> };
> 
> This effectively lets you do stuff like this:
> FOO f;
> int i = f.property();
> f.property() = i;
> 
...
> I really hope the designers of D reconsider this aspect of the language.

  Personally I would say that doing it somewhat similarly to how MSVC
does it:

struct A
{
	int GetA() { return a; }
	int PutA( int newA ) { a= newA; }

	int a;

	__declspec( property( get=GetA, put=PutA ) )
		int a;
};

so:
  A a;

  a.a= 2; // calls PutA( 2 )

  cout << a.a;  // calls GetA()

Microsofts implementation is nice for the users of the class, but somewhat cumbersome for the designers of the class.

Perhaps a better way is:

struct A
{
	gettor( a ) int GetA() { return a; }
	settor( a ) int PutA( int newA ) { a= newA; }

	int a;
};

or even:

struct A
{
	int GetA() { return a; }
	int PutA( int newA ) { a= newA; }

	settor( PutA ) gettor( GetA ) int a;
	// access( PutA, GetA ) int a; ??
};

  - Factory

not sure why any of this needs to be done automatic anyway. y not just (like java does) leave it all to be explicitly defined by programmer?

It's a simple matter of readability.  Getters/setters look a lot nicer than get/set methods.  Which do you prefer:

	window.SetWidth(window.GetWidth() + 10)
or
	window.Width += 10;

Another example is a rectangle struct that exposes x, y, width, height, top, left, bottom, and right properties all at once, and allows all to be read or written as suits the situation at hand.

There's also nice (though arguably naughty) tricks like making a variable public, then later wrapping it up into a getter/setter when it becomes necessary, without changing the public interface.

You do have a point; getter/setters are just syntactic sugar.  But they're kind of sugar that helps make a lot of things simpler and more intuitive, and just a Very Good Thing to have in general.

Paul Stanton wrote:
> not sure why any of this needs to be done automatic anyway. y not just (like
> java does) leave it all to be explicitly defined by programmer?
> 
> 

yeah, i c ur point.

but personally, i would take the hit for the following reason...
By nature, getters and setters dont have to be simple getters and setters. they
can (some cases should not) contain logic. therefore, i would want it explicit
that i was using programmer defined methods ("x.setY(x.getY()+10)"), rather then
an operator ("x.y+=10").

In article <b07ndv$24tn$1@digitaldaemon.com>, Andy Friesen says...
>
>It's a simple matter of readability.  Getters/setters look a lot nicer than get/set methods.  Which do you prefer:
>
>	window.SetWidth(window.GetWidth() + 10)
>or
>	window.Width += 10;
>
>Another example is a rectangle struct that exposes x, y, width, height, top, left, bottom, and right properties all at once, and allows all to be read or written as suits the situation at hand.
>
>There's also nice (though arguably naughty) tricks like making a variable public, then later wrapping it up into a getter/setter when it becomes necessary, without changing the public interface.
>
>You do have a point; getter/setters are just syntactic sugar.  But they're kind of sugar that helps make a lot of things simpler and more intuitive, and just a Very Good Thing to have in general.
>
>Paul Stanton wrote:
>> not sure why any of this needs to be done automatic anyway. y not just (like java does) leave it all to be explicitly defined by programmer?
>> 
>> 
>

If you want to be *really* explicit, you can use assembly. ;)  I prefer to abstract things when it makes life easier.

Having properties (the C# term for getter/setters) perform logic as well as assign values is the whole point.  Checking bounds, or relaying to an external API along with an assignment is a useful idiom that, like anything, can be misused.  It's just a matter of whether it's easy enough to use properly, and worth the potential for "evil."

In the case of properties, I would say that they're well worth it.

Paul Stanton wrote:
> yeah, i c ur point.
> 
> but personally, i would take the hit for the following reason...
> By nature, getters and setters dont have to be simple getters and setters. they
> can (some cases should not) contain logic. therefore, i would want it explicit
> that i was using programmer defined methods ("x.setY(x.getY()+10)"), rather then
> an operator ("x.y+=10").
> 
> In article <b07ndv$24tn$1@digitaldaemon.com>, Andy Friesen says...
> 
>>It's a simple matter of readability.  Getters/setters look a lot nicer than get/set methods.  Which do you prefer:
>>
>>	window.SetWidth(window.GetWidth() + 10)
>>or
>>	window.Width += 10;
>>
>>Another example is a rectangle struct that exposes x, y, width, height, top, left, bottom, and right properties all at once, and allows all to be read or written as suits the situation at hand.
>>
>>There's also nice (though arguably naughty) tricks like making a variable public, then later wrapping it up into a getter/setter when it becomes necessary, without changing the public interface.
>>
>>You do have a point; getter/setters are just syntactic sugar.  But they're kind of sugar that helps make a lot of things simpler and more intuitive, and just a Very Good Thing to have in general.
>>
>>Paul Stanton wrote:
>>
>>>not sure why any of this needs to be done automatic anyway. y not just (like
>>>java does) leave it all to be explicitly defined by programmer?
>>>
>>>
>>
> 
> 

In article <b07oae$25bl$1@digitaldaemon.com>, Paul Stanton says...
>
>yeah, i c ur point.
>
>but personally, i would take the hit for the following reason...
>By nature, getters and setters dont have to be simple getters and setters. they
>can (some cases should not) contain logic. therefore, i would want it explicit
>that i was using programmer defined methods ("x.setY(x.getY()+10)"), rather then
>an operator ("x.y+=10").

Maybe as a matter of style, the programmer should capitalize the first letter of the property to distinguish it from regular public variables. Perhaps that should go in the style guide. (Once properties are implemented.)

>
>In article <b07ndv$24tn$1@digitaldaemon.com>, Andy Friesen says...
>>
>>It's a simple matter of readability.  Getters/setters look a lot nicer than get/set methods.  Which do you prefer:
>>
>>	window.SetWidth(window.GetWidth() + 10)
>>or
>>	window.Width += 10;
>>
>>Another example is a rectangle struct that exposes x, y, width, height, top, left, bottom, and right properties all at once, and allows all to be read or written as suits the situation at hand.
>>
>>There's also nice (though arguably naughty) tricks like making a variable public, then later wrapping it up into a getter/setter when it becomes necessary, without changing the public interface.
>>
>>You do have a point; getter/setters are just syntactic sugar.  But they're kind of sugar that helps make a lot of things simpler and more intuitive, and just a Very Good Thing to have in general.
>>
>>Paul Stanton wrote:
>>> not sure why any of this needs to be done automatic anyway. y not just (like java does) leave it all to be explicitly defined by programmer?
>>> 
>>> 
>>
>
>

Why does everything have to be so damned explicit?!!

And how is "x.setY(x.getY()+10)" any more understandable than "x.y+=10"??

The problem here is your preconceived notions of what programming is about. I for one do not want to be forced to be explicit about every little detail of execution.  Taken to the extreme that would eliminate *ALL* code reuse.

I *LIKE* the idea of the compiler understanding something more similar to my native language, instead of forcing me to use its alien computer tongue.

D has an opportunity here to "rewrite the rules" so to speak.  I'd carefully consider any artificial limitations.

Sean

"Paul Stanton" <Paul_member@pathlink.com> wrote in message news:b07oae$25bl$1@digitaldaemon.com...
> yeah, i c ur point.
>
> but personally, i would take the hit for the following reason...
> By nature, getters and setters dont have to be simple getters and setters.
they
> can (some cases should not) contain logic. therefore, i would want it
explicit
> that i was using programmer defined methods ("x.setY(x.getY()+10)"),
rather then
> an operator ("x.y+=10").