Properties: a.b.c = 3

[Chad J]

Steven Schveighoffer wrote:
> On Wed, 29 Jul 2009 14:46:11 -0400, Chad J
> <chadjoan at __spam.is.bad__gmail.com> wrote:
> 
>> grauzone 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...
>>>
>>> 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.)
>>>
>>> As for the rest, I'm sure all of you will have figured it out after some
>>> more ~500 postings.
>>
>> But you don't /have/ to type out that mess!  Why would anyone do that?!
>>  It's madness.
>>
>> The compiler does it FOR you.  That's why it's there.  It is supposed to
>> save you from doing tedious work.
>>
>> Currently there are some cases where the current paradigm forces you to
>> do that kind of work by hand:
>>
>> struct Rectangle
>> {
>>     float x,y,w,h;
>> }
>>
>> class Widget
>> {
>>     Rectangle _rect;
>>     Rectangle rect() { return _rect; }
>>     Rectangle rect(Rectangle r) { return _rect = r; }
>>     // etc
>> }
>>
>> void main()
>> {
>>     auto widget = new Widget();
>>
>>     // DOES WORK:
>>     auto tmp = widget.rect;
>>     tmp.w = 200;
>>     tmp.h = 100;
>>     widget.rect = tmp;
>>
>>     // DOES NOT WORK:
>>     // widget.rect.w = 200;
>>     // widget.rect.h = 100;
>> }
> 
> Wouldn't the compiler write:
> 
> //widget.rect.w = 200 translates to
> auto tmp1 = widget.rect;
> tmp1.w = 200;
> widget.rect = tmp1;
> 
> //widget.rect.h = 100 translates to
> auto tmp2 = widget.rect;
> tmp2.h = 100;
> widget.rect = tmp2;
> 
> ???
> 
> Unless you want some serious optimization requirements...
> 
> -Steve

It would.

The optimization you speak of is reference caching.  I often do it by
hand in deeply nested loops where it actually means a damn.  It's also
an optimization I think compilers should do, because it is useful in
many more cases than just this.

Using some manner of property syntax would not preclude the programmer
from writing the optimized version of the code by hand.