Accessors, byLine, input ranges

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Jan 29 09:23:24 PST 2010


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.

Andrei



More information about the Digitalmars-d mailing list