byKey and byValue: properties or methods?

[Steven Schveighoffer]

On Wed, 18 Jan 2012 09:13:37 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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