Accessors, byLine, input ranges
Michel Fortin
michel.fortin at michelf.com
Fri Jan 29 11:44:53 PST 2010
On 2010-01-29 13:52:25 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail at 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.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list