Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
I think the only way you and Walter can understand what a property
is and what it is used for is to use for some time a language that
implements them. For example C#. Then you'll say "that's nice" and
would want to implement it in D.
I totally agree that "that's nice". But it's just notational
convenience, and there was no proof aired here to convince me
otherwise.
Andrei
The ambiguity with a function returning a delegate? The debugger
support? Help UI designers with properties windows?
If none of those convinced you, ok.
Convince me of what? Of the fact that the current design has problems,
absolutely. That we need to embark on all sorts of baroque notations
for the sake of a convenience, not quite.
Andrei
I agree. It's very hard to find the correct way to implement it... :(
Might be because (a) we aren't getting our priorities right, (b) we
ascribe more to properties than what the compiler really makes of them.
At the end of the day, a property is a notational convenience. Instead
of writing:
obj.set_xyz(5);
int a = obj.get_xyz();
properties allow us to write:
obj.xyz = 5;
int a = obj.xyz;
Just to be 100% clear, I agree that the convenience is great. But I
don't know why the hell I need to learn a whole different syntax for
*defining* such things, when the compiler itself doesn't give a damn -
it just blindly rewrites the latter into something like the former.
Now to be 101% clear, I also understand that the current design sucks.
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.
Andrei
