On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
<seewebsiteforem...@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. I admit this is a good example where a judgement call
comes into play, but we aren't all robots obeying every rule literally.
There are sometimes exceptions in conventions, or at least the rule is
subject to interpretation.
-Steve
