Bill Baxter wrote:
On Wed, Jul 29, 2009 at 9:23 AM, Jarrett
Billingsley<[email protected]> wrote:
On Wed, Jul 29, 2009 at 10:44 AM, Ary Borenszweig<[email protected]> wrote:
Andrei Alexandrescu wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
The question is very simple: given that we're used with a
specific semantics for a.b.c = 3, how can we address the fact
that the semantics of this familiar operation is so different
(and likely so useless) when properties replace fields?
You're solving problems that never came to life. Well... only as
syntetic examples.
IMHO it's quite the contrary, a.b.c = 3 is a very simple and
concrete problem that emphatically shows we haven't gotten
properties up to snuff.
Never saw this problem in C#.
Of course you didn't. This is because C# doesn't have it - their structs
can't define properties.
Andrei
Yes they can. And also C# shows us the solution to the problem (similar to
what Walter proposed).
---
public class Bar
{
public Foo Foo { get; set; }
}
public struct Foo
{
public int Property { get; set; }
}
Bar bar = new Bar();
Foo foo = new Foo();
foo.Property = 10;
bar.Foo = foo;
bar.Foo.Property = 20; // line 16
---
Error on line 16: Cannot modify the return value of 'Bar.Foo' because it is
not a variable
Booom, exactly what I said about rvalues.
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It's the same issue whether you have properties or not, and
needs a solution whether you have properties or not.
--bb
Probably Walter means
a.b.c = 3; // b is a field
works, while
a.b.c = 3; // b is a getter
is a useless call. Nevertheless, if b() uses ref-return then it is
meaningful.
