byKey and byValue: properties or methods?

[Steven Schveighoffer]

On Wed, 18 Jan 2012 09:40:00 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

All of your arguments were subjective "doesn't palpably change the  
language" "all it does it generate these [in your opinion] useless  
discussions", why can't mine be?

And you did say you were right, when clearly you are wrong :)

>
>>>> 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 language defines the mechanisms of enforcement, not when to use them.   
Any time it's a human interpretation of something, the language has to  
step back and say "you're the boss, you tell me what to do and I'll  
enforce it."  The problem with the current situation is that there is no  
enforcement.  You can suggest a certain usage, and be completely ignored.

I liken it to case sensitivity.  We could say symbol names aren't case  
sensitive, and that anyone can use any casing to call a function.  But  
then the author of the function has lost control of what his function  
names look like.

Since D enforced case sensitivity from the beginning, there is never a  
post saying "should this function be called isUseless or IsUseless.   
Grr... why on earth do we have case sensitivity anyways, it just generates  
useless discussions!"

But go try to suggest to some language community that has case insensitive  
symbols that they should add case sensitivity enforcement, and you'll get  
shit like that.

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

The error in that sentence is "has zero impact."  It has an impact, about  
as significant as choosing a good symbol name.

-Steve