On 2009-07-28 22:33:53 -0400, Walter Bright <[email protected]> said:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
With the local namespace approach I propsed a little while ago, you
could allow "subproperties":
namespace a {
namespace b {
namespace c {
int opGet() {...}
void opAssign(int) {...}
}
}
}
or (alternate syntax for the above):
int a.b.c.opGet() {...}
void a.b.c.opAssign(int) {...}
Although it'd be somewhat clumbersome to redefine every member of a
struct like this each time you make a property just so assigning to it
works fine (I guess a mixin or some compiler magic could help).
I don't see how C#'s special property syntax adds any value for dealing
with this.
Me neither.
One thought I had was to simply disallow the '.' to appear after a
function style property.
I think that's a little harsh. If you return something by reference
(like an object), the waterver you do to that object won't be lost.
It's for value types (like structs) that this is a problem.
--
Michel Fortin
[email protected]
http://michelf.com/