DIP23 draft: Fixing properties redux

[Chad Joan]

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.