Jump to page: 1 2 3
Thread overview
What about putting array.empty in object.d?
Mar 21, 2012
Nick Sabalausky
Mar 21, 2012
Andrej Mitrovic
Mar 21, 2012
H. S. Teoh
Mar 21, 2012
Daniel Murphy
Mar 21, 2012
Xinok
Mar 21, 2012
Jonathan M Davis
Mar 21, 2012
Nick Sabalausky
Mar 21, 2012
Jonathan M Davis
Mar 21, 2012
Daniel Murphy
Mar 21, 2012
Jonathan M Davis
Mar 22, 2012
Jonathan M Davis
Mar 22, 2012
Jonathan M Davis
Mar 22, 2012
Jonathan M Davis
Mar 22, 2012
Jonathan M Davis
Mar 21, 2012
Jacob Carlborg
Mar 21, 2012
Nick Sabalausky
Mar 21, 2012
Jacob Carlborg
Mar 21, 2012
Jonathan M Davis
Mar 21, 2012
Jacob Carlborg
Mar 21, 2012
Simen Kjærås
Mar 25, 2012
Jacob Carlborg
March 21, 2012
Hear me out... ;)

Using empty seems to be emerging as the recommended practice for testing whether an array is empty. And that makes sense as it's consistent with other ranges. I'm all in favor of that.

But I've found myself avoiding empty (and instead doing arr=="" or checking the .length) just because empty doesn't work on arrays unless you've already imported std.array (unless my knowledge is out-of-date, which is possible considering how fast things are moving ;) ). So doing "arr.empty" is a little messy and increases my cognitive load, whereas arr=="", arr==[], and arr.length == 0, "just work".

Considering that:

1. Arrays are (from the user's perspective) a built-in type that doesn't need to be explicitly imported.

2. Calling 'empty' is (for good reason) the recommended standard practice for checking if arrays are empty.

...Perhaps it would make sense for empty(T)(T[] a) to be moved into object.d, or at least somewhere it will always be implicitly included? Being a standard part of arrays and input ranges already effectively elevates "empty" to a relatively special status anyway.


March 21, 2012
On 3/21/12, Nick Sabalausky <a@a.a> wrote:
> Hear me out... ;)

Man I would say the same thing about write() functions. I've missed importing std.stdio so many times. It doesn't help that the compiler happily asks me if I've missed an import to std.stdio. But I digress..

I use .length all the time. I also use them on hashes and it sucks that .empty isn't defined for them (it's not in std.array).
March 21, 2012
On Wed, Mar 21, 2012 at 05:27:01AM +0100, Andrej Mitrovic wrote:
> On 3/21/12, Nick Sabalausky <a@a.a> wrote:
> > Hear me out... ;)
> 
> Man I would say the same thing about write() functions. I've missed importing std.stdio so many times. It doesn't help that the compiler happily asks me if I've missed an import to std.stdio. But I digress..
> 
> I use .length all the time. I also use them on hashes and it sucks that .empty isn't defined for them (it's not in std.array).

Good point! I'll have to add .empty to my AA implementation. ;-)


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth
March 21, 2012
FWIW, I would rather see `if (array)` translated to `if (array.length)` and this become the recomended way to check if an array is empty.  Wouldn't that remove the dependency on std.array for most of the cases?


March 21, 2012
On 2012-03-21 04:54, Nick Sabalausky wrote:
> Hear me out... ;)
>
> Using empty seems to be emerging as the recommended practice for testing
> whether an array is empty. And that makes sense as it's consistent with
> other ranges. I'm all in favor of that.
>
> But I've found myself avoiding empty (and instead doing arr=="" or checking
> the .length) just because empty doesn't work on arrays unless you've already
> imported std.array (unless my knowledge is out-of-date, which is possible
> considering how fast things are moving ;) ). So doing "arr.empty" is a
> little messy and increases my cognitive load, whereas arr=="", arr==[], and
> arr.length == 0, "just work".
>
> Considering that:
>
> 1. Arrays are (from the user's perspective) a built-in type that doesn't
> need to be explicitly imported.
>
> 2. Calling 'empty' is (for good reason) the recommended standard practice
> for checking if arrays are empty.
>
> ...Perhaps it would make sense for empty(T)(T[] a) to be moved into
> object.d, or at least somewhere it will always be implicitly included? Being
> a standard part of arrays and input ranges already effectively elevates
> "empty" to a relatively special status anyway.

Sure, why not. Do we want an "any" function as well, that is the opposite?

-- 
/Jacob Carlborg
March 21, 2012
"Jacob Carlborg" <doob@me.com> wrote in message news:jkc321$25pv$1@digitalmars.com...
> On 2012-03-21 04:54, Nick Sabalausky wrote:
>> Hear me out... ;)
>>
>> Using empty seems to be emerging as the recommended practice for testing whether an array is empty. And that makes sense as it's consistent with other ranges. I'm all in favor of that.
>>
>> But I've found myself avoiding empty (and instead doing arr=="" or
>> checking
>> the .length) just because empty doesn't work on arrays unless you've
>> already
>> imported std.array (unless my knowledge is out-of-date, which is possible
>> considering how fast things are moving ;) ). So doing "arr.empty" is a
>> little messy and increases my cognitive load, whereas arr=="", arr==[],
>> and
>> arr.length == 0, "just work".
>>
>> Considering that:
>>
>> 1. Arrays are (from the user's perspective) a built-in type that doesn't need to be explicitly imported.
>>
>> 2. Calling 'empty' is (for good reason) the recommended standard practice for checking if arrays are empty.
>>
>> ...Perhaps it would make sense for empty(T)(T[] a) to be moved into
>> object.d, or at least somewhere it will always be implicitly included?
>> Being
>> a standard part of arrays and input ranges already effectively elevates
>> "empty" to a relatively special status anyway.
>
> Sure, why not. Do we want an "any" function as well, that is the opposite?
>

I think "!array.empty" is plenty sufficient. Besides, there are other good uses of "any" that have been brought up before.


March 21, 2012
On 2012-03-21 09:42, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
>> Sure, why not. Do we want an "any" function as well, that is the opposite?
>>
>
> I think "!array.empty" is plenty sufficient. Besides, there are other good
> uses of "any" that have been brought up before.

Actually I was thinking something like "any?" in Ruby:

http://www.ruby-doc.org/core-1.8.7/Enumerable.html#method-i-any-3F

-- 
/Jacob Carlborg
March 21, 2012
On Wed, 21 Mar 2012 00:54:51 -0400, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> FWIW, I would rather see `if (array)` translated to `if (array.length)` and
> this become the recomended way to check if an array is empty.  Wouldn't that
> remove the dependency on std.array for most of the cases?

+1

-Steve
March 21, 2012
On Wednesday, 21 March 2012 at 04:54:54 UTC, Daniel Murphy wrote:
> FWIW, I would rather see `if (array)` translated to `if (array.length)` and
> this become the recomended way to check if an array is empty.  Wouldn't that
> remove the dependency on std.array for most of the cases?

Nope. .length is a requirement for finite random-access ranges, but not for forward or bidirectional ranges. .empty is the only primitive required by all input ranges.

So if you pass an array to a function expecting a forward range, it may not work if the primitive .empty doesn't exist.
March 21, 2012
On Wed, 21 Mar 2012 11:50:46 -0400, Xinok <xinok@live.com> wrote:

> On Wednesday, 21 March 2012 at 04:54:54 UTC, Daniel Murphy wrote:
>> FWIW, I would rather see `if (array)` translated to `if (array.length)` and
>> this become the recomended way to check if an array is empty.  Wouldn't that
>> remove the dependency on std.array for most of the cases?
>
> Nope. .length is a requirement for finite random-access ranges, but not for forward or bidirectional ranges. .empty is the only primitive required by all input ranges.
>
> So if you pass an array to a function expecting a forward range, it may not work if the primitive .empty doesn't exist.

from std/range.d:

module std.range;

public import std.array;

-Steve
« First   ‹ Prev
1 2 3