View mode: basic / threaded / horizontal-split · Log in · Help
January 25, 2008
Re: In expression for array
kede wrote:
>  if ('i' in eyes)
>  ...
> 
> as a simple replacement for the more verbose
>  foreach(c; eyes)
>    if (c == 'i')
>      ...

I want to add few things to this discussion:
- D already has opIn and opIn_r, so it's just a matter of using it.
- If you use a language with the in built in (D has it already, but I meant for arrays), like Python, you can quickly understand why it's very good to have it built-in. (Generally if you come from a language that lacks something, then it becomes less easy to see why/where it's useful. I know some things aren't good if you put them in another language, but it's not this situation, I think).
- Using the foreach(c; eyes) if (c == 'i'){} pattern is bad because you always use a O(n) scan regardless what that "eyes" is. But maybe "eyes" is an object with a opIn_r method that is O(ln n) or O(1), and you miss it. Instead if you use "in" (that is you use opIn_r) you always use the faster way of finding the presence of an item the object allows you to (if no opIn_r is defined, but opApply is defined, then the "in" operator must automatically call opApply to perform a scan).
- So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-)

Bye,
bearophile
January 25, 2008
Re: In expression for array
On Jan 25, 2008 7:25 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> - So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-)

All good points. But I know that part of the reason it's a no-go is
consistency. "in" has to scan the keys, not the values, or it would be
inconsistent with AAs.

Personally I wouldn't mind dropping "in" in favor of two new infix
functions "contains" and "containsKey", which would disambiguate the
two cases (and give extra functionality for AAs). But it's probably
too late to change things now, so forget I said anything. :-)
January 25, 2008
Re: In expression for array
Janice Caron wrote:
> On Jan 25, 2008 7:25 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> 
>>- So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-)
> 
> 
> All good points. But I know that part of the reason it's a no-go is
> consistency. "in" has to scan the keys, not the values, or it would be
> inconsistent with AAs.
> 

Which doesn't stop Python from doing it this way. And it makes perfect 
sense. In an AA, you are typically concerned with whether a given key 
exists in the container. With an array, you are typically concerned with 
whether a given item is somewhere in the array. Arrays and associative 
arrays are fundamentally different, and I'm not sure this consistency 
actually buys us anything.

And, obviously, using 'in' to check whether a given index is in an array 
is basically useless. Using it as a containment check is /much/ more 
useful. So what if arrays and AAs act differently? You can't assign to 
an arbitrary non-existent index in an array, or append to an AA, either. 
They are not substitutes for each other.

> Personally I wouldn't mind dropping "in" in favor of two new infix
> functions "contains" and "containsKey", which would disambiguate the
> two cases (and give extra functionality for AAs). But it's probably
> too late to change things now, so forget I said anything. :-)

These can already be done as library functions, if there's that much 
concern about it.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
January 25, 2008
Re: In expression for array
bearophile wrote:
> kede wrote:
>>  if ('i' in eyes)
>>  ...
>>
>> as a simple replacement for the more verbose
>>  foreach(c; eyes)
>>    if (c == 'i')
>>      ...
> 
> I want to add few things to this discussion:
> - D already has opIn and opIn_r, so it's just a matter of using it.
> - If you use a language with the in built in (D has it already, but I meant for arrays), like Python, you can quickly understand why it's very good to have it built-in. (Generally if you come from a language that lacks something, then it becomes less easy to see why/where it's useful. I know some things aren't good if you put them in another language, but it's not this situation, I think).
> - Using the foreach(c; eyes) if (c == 'i'){} pattern is bad because you always use a O(n) scan regardless what that "eyes" is. But maybe "eyes" is an object with a opIn_r method that is O(ln n) or O(1), and you miss it. Instead if you use "in" (that is you use opIn_r) you always use the faster way of finding the presence of an item the object allows you to (if no opIn_r is defined, but opApply is defined, then the "in" operator must automatically call opApply to perform a scan).
> - So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-)
> 
> Bye,
> bearophile

bool has(T)(T[] arr, T elem) {
   foreach (a; arr) if (a == elem) return true;
   return false;
}

if (myarray.has(3)) {
   // ...
}

Just as good, imhoe. You can't avoid a linear scan unless you know 
whether the array is sorted.
Top | Discussion index | About this forum | D home