On 1/18/12 8:34 AM, Steven Schveighoffer wrote:
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 :)
Indeed I told you all! Every time we add anything, there's going to be
sh... stuff like this.
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.
This is not an argument. It's good because it's like in other languages
where it's supposed to be good. And it's not "the right answer" when
there's nothing to be answered.
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.
If that's the case, then there shouldn't be a black-and-white
distinction in the language about 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.
The fact that reasonable people disagree, and that choosing one way or
another has zero impact on the quality of the code, makes this feature a
costly mistake.
Andrei
