Omittable parens is an evil

[Nick Sabalausky]

"Mike" <vertex at gmx.at> wrote in message news:op.uejk9fs8kgfkbn at lucia...
> On Sat, 19 Jul 2008 15:32:36 +0200, Koroskin Denis <2korden+dmd at gmail.com> 
> wrote:
>
>> Why not have special syntax for properties, like:
>
> This has come up multiple times - that's one of the few things where C# 
> wins over D. If I may repeat a suggestion I made once, maybe Walter can be 
> hypnotized into implementing it if I just repeat it often enough :)
>
> class foo
> {
>     private int _bar;
>     property int bar
>     {
>         opGet() { return _bar; }
>         opSet(auto value) { _bar = value; }
>         opAddAssign(auto value) { _bar += value; } // it's extremely 
> extendable!
>     }
> }
>
> -Mike

I've always been in favor of this sort of thing as well. My reasoning is 
that "member variable" vs "getter/setter function" is an implementation 
detail, and implementation details should be possible to abstract away.

The creator of a library/API/etc should be able to design their classes in 
way such that if a class has a property (for instance, the color of it), 
then the user of the object wouldn't have to stop and think "Ok, now is 
color accessed as a member variable or through getters/setters?". The 
library creator should be able to make it so that it's the same either way.

Additionally, the ability to abstract away the "member variable" vs 
"getter/setter function" distinction would allow a library/API creator to 
develop like this: When first creating a class, the class has a property 
"x". At this point in time, there's nothing special that needs to be done 
when "x" is read from or written to. So implementing "x" as a member 
variable is perfectly sufficient. Later on, the class gains enhancements, 
some of which require additional actions to be taken whenever "x" is 
accessed. You're working on a library/API, so you don't want this change to 
be a breaking one. So instead of needing to religously implement all trivial 
and non-trivial properties as getters/setters right from day one in order to 
avoid this situation, all you'd need to do is say "Ok, property 'x' now 
needs getter/setter functionlity, so I'll convert it into this special 
'property accessing' feature of the language instead of getter/setter 
functions, and that way my change won't break anything."

A third reason: Project management (Although I really think of this sort of 
thing more as being "lead programmer" than "manager". A manager's role is 
administrative, they're there to make sure the developers have what they 
need to do their job - chairs, computers, tools, distraction-free workspace, 
competent co-workers, etc. It's not their role to go sticking their fingers 
into the code. But I digress.). Just like how the built-in unittests, 
documentation, invariants, and debug conditionals allow...whoever is in 
charge...to have one less thing to arbitrarily define in their "coding 
standards", this would alliviate the need to define a standard naming 
convention for getters/setters. Whatever standard variable naming convention 
exists would be sufficient.

So, four reasons for a special "property accessing" syntax like the above:

1. The "member variable" vs "getter/setter function" distinction is an 
implementation detail, and as such, should be possible to abstract away.

2. User of a library doesn't always have to think "Ok, now is this property 
implemented as a member variable or as getters/setters?".

3. Creator of a library can change a member variable into a "getter/setter" 
of sorts without it being a breaking change, and without needing to 
religously implement all properties as getters/setters from day one.

4. Lead developer doesn't have to come up with an arbitrary "getter/setter" 
naming convention. They can simply say "Just use the built-in 'property 
accessing' syntax, and follow the usual variable naming conventions".