byKey and byValue: properties or methods?

[Timon Gehr]

On 01/17/2012 02:14 PM, Alex Rønne Petersen wrote:
> On 17-01-2012 13:41, Nick Sabalausky wrote:
>> "Jonathan M Davis"<jmdavisProg at gmx.com> wrote in message
>> news:mailman.496.1326793835.16222.digitalmars-d at puremagic.com...
>>> On Tuesday, January 17, 2012 09:07:04 Alex Rønne Petersen wrote:
>>>> On 17-01-2012 07:48, Andrei Alexandrescu wrote:
>>>>> I hate I must ask this:
>>>>>
>>>>> int[string] aa;
>>>>> foreach (k; aa.byKey) { ... }
>>>>>
>>>>> or
>>>>>
>>>>> int[string] aa;
>>>>> foreach (k; aa.byKey()) { ... }
>>>>>
>>>>
>>>> The "by" in the name is way too awkward for a property. If it was just
>>>> named "keys" and "values", it would've been perfectly fine to make them
>>>> properties, but the "by" just looks awkward when you "call" them as
>>>> properties.
>>>>
>>>> As far as efficiency goes, I don't think these perform any work that is
>>>> heavy enough to warrant not making them properties. (I can't say that
>>>> same for .dup/.idup... I still don't get why those are properties, at
>>>> all.)
>>>
>>> Agreed. If it were keys and values, then a property would make sense.
>>> However,
>>> since it's byKey and byValue, I don't think that it makes as much
>>> sense. It
>>> _is_ a bit of a weird case though, since byKey and byValue are neither
>>> nouns
>>> nor verbs.
>>>
>>
>> You're all getting hung up on the trivial detail of the names. Look at
>> the
>> semantics: They retreive a range associated with the aa, right? Right.
>> Property. It's a plain old classic getter.
>>
>>
>
> That doesn't make the name any less bad. Naming is important IMHO. Hence
> why I'm also complaining about .dup/.idup.
>

I think the compiler should just allow .dup()/.idup(). It would not 
break any existing code.