On 2011-12-13 23:08:43 +0000, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
We could have inferred property intention from the code pattern,
without requiring any keyword. That solution (which was discussed and
rejected in this newsgroup) was miles ahead from the drivel of
@property we have now.
By "code patterns", you mean something like this?
struct Foo
{
int getBar();
void setBar(int);
}
void main()
{
Foo foo;
int a = foo.bar; // calls getBar()
foo.bar = a; // calls setBar(a)
}
I agree it's better. For one thing it'd be much less confusing about
whether it make sense to make something a property or not because you'd
have to write "get" in front of it -- for instance getSave doesn't make
any sense.
And it'd be much less problematic too: the way @property is currently
designed, you can't distinguish between a definition for a an
array-member property getter and a module-level property setter. Also
with the current design you have no way to disambiguate array-member
properties with the same name coming from different modules -- can't
replace array.front with std.range.front(array) when @property is
enforced -- having access to the @property's underlying function would
mitigate this -- std.range.getFront(array) would still work. The above
code pattern would also make it saner to take the address of the getter
function as a separate thing from taking the address of a ref value
obtained from a property.
Personally, I'm skeptical the current property design can work as
intended without introducing many issues like the above. I think
perhaps the biggest mistake was to not implement it fully from the
start at a time where we could easily revert to another proposition if
it proved to be problematic. Unfortunately, now we're stuck with
@property and all its problems… although I'd sure like the design to be
revised.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
