byKey and byValue: properties or methods?

[Andrei Alexandrescu]

On 1/18/12 8:34 AM, Steven Schveighoffer wrote:
> 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 :)

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