Bill Baxter wrote:
On Mon, Jul 27, 2009 at 2:24 PM, John C<[email protected]> wrote:
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
"Andrei Alexandrescu" <[email protected]> wrote in message
news:[email protected]...
But what I want is to come with a new design that adds minimum
aggravation on the learning programmer. If they know how to define a method,
they must know how to define a property. None of that property blah { get
... set ... } crap is necessary.
I can't be nice about this: Any programmer who has *any* aggrivation
learning any even remotely sane property syntax is an idiot, period. They'd
have to be incompetent to not be able to look at an example like this:
// Fine, I'll throw DRY away:
int _width;
int width
{
get { return _width; }
set(v) { _width = v; }
}
And immediately know exactly how the poroperty syntax works.
Sure. My point is that with using standard method definition syntax
there's no need for even looking over an example.
Which is why Steven Schveighoffer's is suggestion is the most pragmatic so
far. You just add a "property" attribute to a regular function definition.
(And it doesn't look ugly, unlike the opGet_/opSet_ idea.)
+1.
That's really all that's needed. A simple flag to say "this function
acts like a field".
Also note that the syntactic sugar could be implemented as library,
using macros. Too bad macros were left to D3.0, even though Walter added
a "macro" keyword. (Which was also a breaking change to the finalized
D1.0, blergh.)
That said, it would be really convenient for mixed compile time/runtime
meta programming to be able to associate additional information to a
method or a field. Like marking a method as property. Java and C# have
attribute syntax for this. This would be useful for reflection,
serialization, IDEs, and other modern day crap like this.
Additionally, a "readonly" modifier would eliminate lots of uses of
properties: often, you just want to make a field not writeable from
outside. Normally, you would make the field private, and add a public
readonly getter. Note that making the field immutable is not enough,
because it can't be written by the class.
