Steven Schveighoffer wrote:
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.
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
