On 2010-01-29 13:52:25 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
Ok this makes sense. So something is a property if fetching it doesn't
mess up the parent object. (Maybe properties should be pure even.)
Logical-pure, to be precise. ;-)
The lingering question is whether you can later use the fetched
property to operate change in the parent object. I guess that it's
reasonable to leave that up to the person defining the object and its
property.
You can already do that with fields, so it make sense you can with
properties too:
class A {
B b;
}
struct B {
int c;
}
A a;
a.b.c = 1; // works!
I guess that's a set of rules that is simple, borderline meaningful,
and easy to follow. By that logic File.byLine is a property,
Stack.pop() is a function, Stack.top and Stack.empty are properties etc.
That being said, I agree with Pelle that actions invoked without parens
are darn attractive.
And I agree too, they're attractive. But in a programming language I
prefer to deal with less ambiguities even if it means a few more
parenthesis.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
