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
Rare? What? No. Where is your data?
My anecdotal experience is contradictory. I tend to end up with A LOT
of things that I'd like to make into public variables but don't due to
the risk of breaking encapsulation. The boilerplate can really suck.
I would argue that being able to do the /right/ thing in a /convenient/
way is a very important feature.
I also do not see how this would lead to more features. If anything,
everyone seems to draw the line at address-of: it's a potential feature
that we /don't/ want because it's too complicated and introduces harmful
semantics.
There are a finite amount of features that are needed to make D's
property implementation very complete. Throw them all on the table and
D will have /the best/ property implementation. If, instead, you are
chintzy and give people only some of them, then you will get constant
property discussions on the news group and it will /seem/ like you're
having to implement an endless stream of features.
