Properties: a.b.c = 3

[grauzone]

Steven Schveighoffer wrote:
> On Wed, 29 Jul 2009 14:22:26 -0400, grauzone <none at example.net> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Wed, 29 Jul 2009 10:16:33 -0400, grauzone <none at example.net> wrote:
>>>
>>>> Daniel Keep wrote:
>>>>> Maybe the compiler could rewrite the above as:
>>>>>  auto t = a.b;
>>>>> t.c = 3;
>>>>> a.b = t;
>>>>>  Unless it can prove it doesn't need to.  Same solution as to the op=
>>>>> conundrum.
>>>>
>>>> Yes! At least that's what the user wants.
>>>>
>>>> The compiler has to detect, that the object was modified at all. (To 
>>>> know whether it should generate code to write back the property.) 
>>>> Would this make the compiler much complexer?
>>>>
>>>> You also have to deal with nested properties:
>>>>
>>>> a.b.c.d = 3;
>>>>
>>>> turns to
>>>>
>>>> auto t = a.b;
>>>> auto t2 = t.c;
>>>> c.d = 3;
>>>> t.c = t2;
>>>> a.b = t;
>>>>
>>>> ???
>>>  Yeah, I think this idea is no good.  a.b.c.d.e.f = 3, results in one 
>>> gigantic mess, which the user might not want.
>>
>> I don't want to type out that mess as a user either...
> 
> What I meant was, I wouldn't want something like a.b.c.d.e.f = 3 to 
> generate the equivalent of 25 lines of code.

The thing above was just the consequence of Daniel Keep's idea of 
writing back those modified temporary values.

In the common case, you wouldn't use such deep nesting anyway.

>> Design changes to avoid that mentioned mess would interfere with the 
>> goal of abstraction (e.g. assume you have widget.position, now how do 
>> you set only the x coordinate? yeah, split the property into 
>> position_x and position_y. Result is you have more noise, and you 
>> can't use a Point struct.)
> 
> option 1, return a ref Point struct

Then I can it make just a field. The reason that one makes this a 
property are:
1. Want to catch writes with a getter.
2. Wants to make it read-only (you had to return a const reference, 
which probably would make the implementation of Point a bit annoying: 
you had to mark methods as const etc.)

> option 2, return a special struct which uses properties to set the 
> values in the original widget.

Now this would generate a mess (lots of bloat). Now I'm not sure; maybe 
macros could provide a way out (auto generate the code bloat), or 
possibly you could use alias this to properly "wrap" a value? Any ideas 
on this?

> 
> I don't think it's an impossible problem to solve, I just don't think 
> the compiler should be involved, because it makes it too easy to 
> gerenate horrible code.
> 
> Now, having the compiler reject invalid assignments is definitely 
> something I can live with.

This would be better than the status quo, yes.

> -Steve