Properties: a.b.c = 3

[Michel Fortin]

On 2009-07-30 15:32:58 -0400, "Nick Sabalausky" <a at a.a> said:

> C# shows us *A* solution. Doesn't mean we can't do one better.
> 
> The whole point of properties is that, to the outside observer, they behave,
> as much as possible, like plain fields. Obviously this can't be done in all
> cases (like getting an int* from &myIntProp), but in this case:
> 
> widget.sizeAsAStructField.width = 10; // Works
> widget.sizeAsAStructProp.width = 10; // Doesn't work
> 
> ...we absolutely can fix that even if C# doesn't.

I'm undecided about what to do here.

But I'd like to note that while common in our current examples, 
assignment to a member of the returned struct is *one* thing that can 
change the struct. Any function taking a non-const reference to the 
struct can also change it. For instance, let's add a call to a mutator 
for the size struct of your example:

	widget.sizeAsStructProp.increaseBy(10, 10);

In this case, you'll also want the compiler automatically call the 
setter once it's done. And that doesn't apply only to member functions, 
you could define it a standalone function taking a ref to the struct 
and call it that way:

	increaseSizeBy(widget.size.sizeAsStructProp, 10, 10);

In all those cases, you'll want to call the setter back once the struct 
has been modified.

Don't take this as an argument for or against automatically setting the 
modified struct property value; I'm just pointing out that operators 
(and specially the assignment operator) isn't the only way to change a 
value. Assuming the non-mutator functions take a const ref to the 
struct, the compiler should be able to avoid setting back the property 
value when it's not necessary.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/