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