January 17, 2012
On Tuesday, January 17, 2012 14:14:46 Alex Rønne Petersen wrote:
> That doesn't make the name any less bad. Naming is important IMHO. Hence why I'm also complaining about .dup/.idup.

save for forward ranges is pretty much the same. It's a property even though it's name and usage suggests otherwise. But we're pretty much stuck with all three of those at this point. Arguing about it is pretty much quibbling over straws, and some - Andrei in particular - are becoming increasingly adverse to arguing over such small changes to existing code for minimal benefit.

- Jonathan M Davis
January 17, 2012
On 17/01/12 6: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

byKey(aa)

Roll a dice, choose one at random.

The only thing properties are good for is distracting us from tabs vs. spaces debates, and other really, really important matters.
January 17, 2012
> Is this code now working? (I have tried it hours ago):

After the last change it now works, thank you.
I will close/update the relative Bugzilla Issues.

Bye,
bearophile
January 17, 2012
"Alex Rønne Petersen" <xtzgzorex@gmail.com> wrote in message news:jf3s86$1opl$1@digitalmars.com...
> On 17-01-2012 13:41, Nick Sabalausky wrote:
>>
>> 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.

Right, I was only addressing the original matter "property or function?"

> Hence why I'm also complaining about .dup/.idup.
>

Yes, dup/idup are clearly not properties. But they're from way before @property, so of course that's why they are how they are (Not that it's good for them to be that way). I'm also in favor of the suggestion of at least optionally allowing dup()/idup().


January 17, 2012
On 01/17/2012 07:38 PM, Timon Gehr wrote:
> 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. ;)


Can't we drop the empty (). It's too much typing.
You don't need them in Delphi and Delphi has properties.

January 17, 2012
On Tuesday, January 17, 2012 20:27:41 Timon Gehr wrote:
> 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.

@property is in TDPL. It's definitely the plan to implement it as described in TDPL, integrating -property into the compiler so that @property is _always_ enforced. It's just not that way, because it's on the list of things that's not fully implemented, and we needed a migration path from no @property enforcement to enforcement.

You would need to come up with some really solid arguments why it should be thrown out (and what we should do instead) and get both Walter and Andrei (if not the community at large) to agree that they not only prefer your proposal but that it's worth the issues that the changes are going to cause at this stage.

- Jonathan M Davis
January 17, 2012
El 17/01/2012 18:24, Andrei Alexandrescu escribió:
>> On 2012-01-17 06:48:26 +0000, Andrei Alexandrescu
...
>
> aa.keys is taken btw.
>


OK, I see, .keys and .values currently return dynamic arrays.

But the most appropriate property name for the above range should indeed be .keys !

Now, wouldn't it be be better to turn .keys into the proposed range?

Let's see. What is the use of .keys?

I searched phobos and found that .keys is mostly used to itarate over the keys in a foreach loop. With the problem that is needs to allocate a dynamic array. If silently changed to the proposed range, the foreach loop would do the same and without an allocation.

In a few unittests, .keys is followed by .sort, usually to print the keys in order. That would not work... unless the produced range includes a .sort method. Alternatively a .sortedKeys property can be added.

The other use I see in phobos is just a typeof(a.keys[0]), which could be replaced by typeof(a.keys.front)


What is the benefit of .keys as a range? it does not allocate an array, just gives the keys.

And if an array is needed, it is easy to turn a range into an array. [Well, I'm missing a more direct way of doing that than using foreach and appending]

January 17, 2012
On 01/17/2012 11:19 PM, Alvaro wrote:
> El 17/01/2012 18:24, Andrei Alexandrescu escribió:
>>> On 2012-01-17 06:48:26 +0000, Andrei Alexandrescu
> ...
>>
>> aa.keys is taken btw.
>>
>
>
> OK, I see, .keys and .values currently return dynamic arrays.
>
> But the most appropriate property name for the above range should indeed
> be .keys !
>
> Now, wouldn't it be be better to turn .keys into the proposed range?
>
> Let's see. What is the use of .keys?
>
> I searched phobos and found that .keys is mostly used to itarate over
> the keys in a foreach loop. With the problem that is needs to allocate a
> dynamic array. If silently changed to the proposed range, the foreach
> loop would do the same and without an allocation.
>
> In a few unittests, .keys is followed by .sort, usually to print the
> keys in order. That would not work... unless the produced range includes
> a .sort method. Alternatively a .sortedKeys property can be added.
>
> The other use I see in phobos is just a typeof(a.keys[0]), which could
> be replaced by typeof(a.keys.front)
>
>
> What is the benefit of .keys as a range? it does not allocate an array,
> just gives the keys.
>
> And if an array is needed, it is easy to turn a range into an array.
> [Well, I'm missing a more direct way of doing that than using foreach
> and appending]
>

See std.array.array.
January 17, 2012
El 17/01/2012 23:32, Timon Gehr escribió:
> On 01/17/2012 11:19 PM, Alvaro wrote:
>> El 17/01/2012 18:24, Andrei Alexandrescu escribió:
>>>> On 2012-01-17 06:48:26 +0000, Andrei Alexandrescu
>> ...
>>>
>>> aa.keys is taken btw.
>>>
>>
>>
>> OK, I see, .keys and .values currently return dynamic arrays.
>>
>> But the most appropriate property name for the above range should indeed
>> be .keys !
>>
>> Now, wouldn't it be be better to turn .keys into the proposed range?
>>
>> Let's see. What is the use of .keys?
>>
>> I searched phobos and found that .keys is mostly used to itarate over
>> the keys in a foreach loop. With the problem that is needs to allocate a
>> dynamic array. If silently changed to the proposed range, the foreach
>> loop would do the same and without an allocation.
>>
>> In a few unittests, .keys is followed by .sort, usually to print the
>> keys in order. That would not work... unless the produced range includes
>> a .sort method. Alternatively a .sortedKeys property can be added.
>>
>> The other use I see in phobos is just a typeof(a.keys[0]), which could
>> be replaced by typeof(a.keys.front)
>>
>>
>> What is the benefit of .keys as a range? it does not allocate an array,
>> just gives the keys.
>>
>> And if an array is needed, it is easy to turn a range into an array.
>> [Well, I'm missing a more direct way of doing that than using foreach
>> and appending]
>>
>
> See std.array.array.

Oops. Yes, thanks.

So, not bad. In those [infrequent, I'd say] cases needing an array one would do:

 auto keys = array(aa.keys);

even: (unsure if this would work, but somethig similar maybe)

 foreach(k; array(aa.keys).sort)
 {
    ... use the ordered keys
 }
January 17, 2012
Andrei Alexandrescu:

> I hate I must ask this:

I am sorry to see you do something you hate :-(

Regarding your question, I'd like keys/values to require () because they do lot of work to create the dynamic array, while I like byKey/byValue to be properties because (I think) their creation is O(1). But now we can't change keys/values. So I'd like to keep all five of them as properties.

I'd like a byPair property too: http://d.puremagic.com/issues/show_bug.cgi?id=5466

---------------------

There is also the question about code like this: http://d.puremagic.com/issues/show_bug.cgi?id=5075

import std.algorithm;
void main() {
    auto aa = ["red":2, "yellow":3];
    auto r = map(n => n * n)(aa);
}

Bye,
bearophile