DIP23 draft: Fixing properties redux
Chad Joan
chadjoan at gmail.com
Tue Feb 5 06:28:46 PST 2013
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.
More information about the Digitalmars-d
mailing list