byKey and byValue: properties or methods?

[Andrei Alexandrescu]

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.

> 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.

> 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.


Andrei