Accessors, byLine, input ranges

[Steven Schveighoffer]

On Fri, 29 Jan 2010 13:41:43 -0500, Michel Fortin  
<michel.fortin at michelf.com> 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.

Be careful here, don't give Andrei hard criteria for declaring victory ;)

But my larger point was that convention is convention, whether you use  
parentheses to designate what a function does, or the symbol name itself.   
Deciding the convention is liable to suit some and not others.  Some  
people hate the flat terse names of Phobos' modules.  Does that mean those  
people are wrong?  Does that mean Walter and Andrei are wrong?  The only  
thing that is wrong here is deciding there is exactly one right rigid way  
to designate what should and should not be a property.

I think we should have a definition of property convention for Phobos, but  
I don't think it needs to be the *only* way people use properties in their  
own projects.  In fact, it can't be because there is no english (or  
whatever language you use) interpreter in the compiler.

-Steve