Re: Accessors, byLine, input ranges

[Andrei Alexandrescu]

Michel Fortin wrote:
On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu 
<seewebsiteforem...@erdani.org> said:

Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu 
<seewebsiteforem...@erdani.org> wrote:
Consider:

struct Stack(T) {
     T pop();
     ...
}

By your definition, pop() should be a property. It doesn't quite 
strike me as an intuitive decision.

is pop's main purpose to fetch a value or to modify the stack?  I'd 
say the purpose is split equally, so it's not a function whose main 
purpose is to fetch a value.

So now we're down to proportions, nuance, and where "main" goes. You 
made my point. I win.

You win because Steven's definition is not good enough. I said before 
that we should have a authoritative definition. If we really can't 
define how a property should be defined after some reflection, then you 
really win.

My definition is that a property gives access to an aspect of an object 
and doesn't modify it (the getter is essentially logical-const).

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.)

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.

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.


Andrei