Accessors, byLine, input ranges

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> Steven Schveighoffer wrote:
>>> On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu 
>>> <SeeWebsiteForEmail at 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