On 02/05/2013 08:31 AM, Andrei Alexandrescu wrote:
On 2/5/13 3:39 AM, Dmitry Olshansky wrote:
On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 2:04 PM,
Jonathan M Davis wrote:
>> We could save a lot of boilerplate code if we can simply make it
>> variables and
>> property functions guaranteed to be swappable without breaking code.
>
> I think this is quite powerful. The way we can do this is by making
> properties emulate a subset of actual variables.
>
This is the primary real-world proble to solve.
The problem with this approach is feature creep - there will always be
yet another possible case in which a feature helps some case. We need to
put a halt on that.
Unprotected, unchecked member variables that can be get and set without
any hooks into the enclosing structure are rare. That's not the case we
should help and cater for. When that's the case, the entire object is
legitimately a "bag of values" that has only public data.
Andrei
Hmmm. This statement that unchecked public members are rare makes me
wonder if there is a fundamental difference of background here. Things
might be much different if you came from C# or Java instead of C++.
I always get this feeling that Walter and Andrei never truly understood
how to use properties effectively. That's why I bring up C# and Java:
those programmers are very comfortable with properties and know how to
use them. Properties are an alien concept in C programming, and
probably C++ as well. As a result, I wouldn't be surprised at all of
Walter and Andrei haven't really used properties in the same capacity as
the typical C# or Java coder, and thus would think things like
"unchecked public members are rare".
This isn't a bashing post or an ad hominem; I'll try to be informative.
In C# properties actually work very well, or at least they did 8 years
ago when I used them (ignoring Java: those programmers use properties a
lot, but it is a pain). They did not require an enormous amount of
features to gain their power, and D shouldn't either. The primary
differences are these:
(1) C# usually doesn't allow address-of on /anything/.
(2) User-defined value types are rare in C#.
(3) Unambiguous property declaration syntax.
In C# if you try to use a property to return a struct and manipulate a
variable off of that, then the compiler will error because C# never
implemented property rewrites. It didn't matter because value types are
rare. (This may be dated by about 3 years.)
I think that those differences are very solvable in D:
(1) Disallow address-of on anything dealing with @property. No one will
miss it; they didn't expect it to exist in the first place.
(2) Do semantic rewriting on properties. Once you have semantic
rewriting, the value-type-properties problem is SOLVED and never needs
to be revisited again. (Disallowing value types in properties would be
poor course in a language where user-defined value types are very common.)
(3) This is pretty much solved in DIP23 already.
In both Java and C# the initial state of properties has always been a
huge pain. Just because something /might/ be a property in the future,
you always have to make a bunch of boilerplate. Java/C# programmers
probably don't believe in "bags of values"; such things are nonsense if
you want proper encapsulation! People coming from this background are
going to LOVE having a shorthand like "public @property int foo;" that
removes all of the pain from properly encapsulating public state.
Using properties in a properly-constrained system was actually very
enjoyable.
The above is why I don't see feature creep. The D designers probably
don't see where it ends because they've never been to that edge.
I worry that I could be totally wrong about Andrei/Walter's experiences
in these arenas. I don't assert these notions as truth, but instead as
a way of communicating my perceptions. I hope this is informative and
not insulting.
