On Wed, 18 Jan 2012 09:13:37 -0500, Andrei Alexandrescu
<[email protected]> wrote:
On 1/18/12 7:44 AM, Steven Schveighoffer wrote:
The solution is easy, just don't start the discussion. Make a decision
(property or no), and that's the end of it. My intuition says that you
will purposely make the *wrong* choice just to try and get others to
complain so you can "be right".
Well in this case I am right :o). We did a poor job at designing
properties. Anyhow, I honestly asked simply because I found no clear cut
decision. My intuition was that byXxx should be a property but I asked
Walter whose intuition said it should be a method. So we agreed to ask
the newsgroup.
Then I withdraw the "being spiteful" suggestion, it was probably unfair.
But the "I told you" didn't set the tone very well for this discussion :)
The point of required property semantics is that the name of the
function includes whether you need parentheses or not. a.empty does not
have the same tone as a.empty(). The former looks like a field, the
latter looks like an action. It's a subtle bikeshed issue, but so is
naming functions anyways!
Yes, but the problem is this adds additional bikeshedding for no benefit.
If you think the names of things aren't
important, name them whatever you want, but at least you as the author
get to choose instead of the user.
I understand this point. It doesn't reduce the frustration that we have
a feature that does not palpably improve the language.
Disagree on both points :) @property with enforcement is the right
answer, it improves the language significantly, bringing it in line with
most other property-enabled C-like languages.
And if I may add my opinion, byValue and byKey are properties.
I agree. The current code has them as properties. My thoughts are, a
property should reasonably replace a member variable (of which syntax it
mimics). So x.length should be property, x.dup shouldn't. Now byXxx can
be considered member variables but only as long as it's not considered
an lvalue: r.byKey.popFront() does nothing interesting, but would do if
r.byKey were actually a member variable. I think that distinction still
does not impair byXxx's right to be a property.
I think the difference between what should be a property and what
shouldn't is not black and white. There is no easy way to define it.
The best I can come up with is, if it gets something that is logically a
piece of the object, then it should be a property (even if it makes a copy
of that something). If it creates something separate from the object, or
modifies the object, it should be a method.
-Steve
