Accessors, byLine, input ranges

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu 
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> Steven Schveighoffer wrote:
>>>>> On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
>>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>>
>>>>>> How is f.byLine clearer and less ambiguous than f.byLine()? Or 
>>>>>> vice versa for that matter?
>>>>>  Note that properties can be named things other than byLine.
>>>>>  -Steve
>>>>
>>>> What I meant to say is that in the @property landscape the following 
>>>> two conventions become suddenly attractive:
>>>>
>>>> * Do not use @property at all
>>>>
>>>> * Use @property for all nullary functions
>>>>
>>>> And they're bound to save a lot of time to everyone involved.
>>>>
>>>  I think we all agree that setters the way D1 does them are very 
>>> prone to abuse.  So all that is left is no-argument functions.
>>>  There are other alternative conventions to what you stated.  This is 
>>> my convention:
>>>  * use @property where the main purpose of the function is to fetch a 
>>> value (computed or not, modifying the container or not)
>>
>> 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.

> I admit this is a good example where a judgement 
> call comes into play, but we aren't all robots obeying every rule 
> literally.

If that's not enough, I have many others. With braces or names, I obey 
rules literally without any trouble. The problem with @property is, 
there are too many exceptions, judgment calls, and edge cases.

> There are sometimes exceptions in conventions, or at least 
> the rule is subject to interpretation.

Which brings home my point: the entire business of deciding @property or 
not is a waste of everyone's time. There's no simple rule, and there's 
no advantage to be gained after having made the decision one way or another.


Andrei