Properties: a.b.c = 3

[Steven Schveighoffer]

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.

> 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
option 2, return a special struct which uses properties to set the values  
in the original widget.

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.

-Steve