On 2009-07-30 15:32:58 -0400, "Nick Sabalausky" <a...@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.for...@michelf.com
http://michelf.com/
