January 17, 2012
On 1/17/12 11:09 AM, Michel Fortin wrote:
> On 2012-01-17 06:48:26 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> said:
>
>> I hate I must ask this:
>>
>> int[string] aa;
>> foreach (k; aa.byKey) { ... }
>>
>> or
>>
>> int[string] aa;
>> foreach (k; aa.byKey()) { ... }
>
> Is it a verb? If not, it is a property.
>
> But why "by"? Why not just "aa.keys"? It's much more natural. Is "byKey"
> going to consume the associative array like "byLine" does for files?
> Obviously no. So I don't see why you need "by" here.

"Iterate collection by key".

aa.keys is taken btw.


Andrei


January 17, 2012
Andrei Alexandrescu:

> "Iterate collection by key".

Is this code now working? (I have tried it hours ago):

import std.stdio, std.algorithm;
void main () {
    auto aa = ["a":1, "b":2];
    writeln(aa.byValue());
    writeln( map!q{ a * a }(aa.byValue()) );
}


Bye,
bearophile
January 17, 2012
On Tue, 17 Jan 2012 07:48:26 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> I hate I must ask this:
>
> int[string] aa;
> foreach (k; aa.byKey) { ... }
>
> or
>
> int[string] aa;
> foreach (k; aa.byKey()) { ... }
>
>
>
> Thanks,
>
> Andrei "I told you" Alexandrescu

Property.
January 17, 2012
On 01/17/2012 01:41 PM, Nick Sabalausky wrote:
> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
> news:mailman.496.1326793835.16222.digitalmars-d@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.
>
>

In fact, it creates a new copy that can be iterated on.
January 17, 2012
On 01/17/2012 07:48 AM, Andrei Alexandrescu wrote:
> I hate I must ask this:
>
> int[string] aa;
> foreach (k; aa.byKey) { ... }
>
> or
>
> int[string] aa;
> foreach (k; aa.byKey()) { ... }
>
>
>
> Thanks,
>
> Andrei "I told you" Alexandrescu

IMO it does not matter. I think we should just deprecate the -property switch instead of engaging into that kind of fruitless discussion every now and then. ;)
January 17, 2012
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@gmx.com> wrote in message
>> news:mailman.496.1326793835.16222.digitalmars-d@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.
January 17, 2012
On 17-01-2012 19:41, Timon Gehr 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@gmx.com> wrote in message
>>> news:mailman.496.1326793835.16222.digitalmars-d@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.

+1.

-- 
- Alex
January 17, 2012
On Tuesday, January 17, 2012 19:38:47 Timon Gehr wrote:
> IMO it does not matter. I think we should just deprecate the -property switch instead of engaging into that kind of fruitless discussion every now and then. ;)

Then we might as well throw out @property and change TDPL. There's no point to @property without enforcement. I think that that ship has pretty much sailed already.

- Jonathan M Davis
January 17, 2012
Le 17/01/2012 07:48, Andrei Alexandrescu a écrit :
> I hate I must ask this:
> 
> int[string] aa;
> foreach (k; aa.byKey) { ... }
> 
> or
> 
> int[string] aa;
> foreach (k; aa.byKey()) { ... }
> 
> 
> 
> Thanks,
> 
> Andrei "I told you" Alexandrescu

Microsoft guidelines: http://msdn.microsoft.com/en-us/library/ms229054.aspx http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx

Googling "method vs property" gives different answers to this recurring question.
January 17, 2012
On 01/17/2012 07:55 PM, Jonathan M Davis wrote:
> On Tuesday, January 17, 2012 19:38:47 Timon Gehr wrote:
>> IMO it does not matter. I think we should just deprecate the -property
>> switch instead of engaging into that kind of fruitless discussion every
>> now and then. ;)
>
> Then we might as well throw out @property and change TDPL. There's no point to
> @property without enforcement. I think that that ship has pretty much sailed
> already.
>
> - Jonathan M Davis

Since -property is optional I think the relevant ships are still in the haven.