byKey and byValue: properties or methods?

[Steven Schveighoffer]

On Tue, 17 Jan 2012 13:41:07 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:

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

I think the compiler should not be in the business of generating methods  
or properties that could be trivially handled by the library.

The only array-specific properties of an array that the compiler should  
worry about are ptr and length.  Everything else should be a library  
function.

-Steve