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