!isEmpty -> hasElements?

[David Morgan ☯]

I know everyone's used to it by now, but the isEmpty method is a bit
odd:

+ It's far more common to write !foo.isEmpty() than foo.isEmpty()
+ So when it's used it usually reads as a double negative ... "if not
foo has no elements then"
+ It's often even harder to read, as in: !foo.bar().baz().isEmpty()

How about supplementing / replacing with foo.hasElements()?

Cheers

David

[Lasse R.H. Nielsen]

Personally, I like it. :)

I'd prefer supplementing, since I also have a lot of places where I
use isEmpty unnegated.
/L
--
Lasse R.H. Nielsen
l...@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K -
Denmark - CVR nr. 28 86 69 84

[Ladislav Thon]

> How about supplementing / replacing with foo.hasElements()?

Personally, I like it. :)

I'd prefer supplementing, since I also have a lot of places where I
use isEmpty unnegated.

Agreed. Not sure about the hasElements name, though, something shorter would be nice (but I don't know what should it look like :-) ).

LT

[David Morgan ☯]

hasContent

hasItems

hasData

?

[Simon Richardson]

isNonEmpty?

[James Ots]

isNotEmpty?

[Dirk Detering]

Am 11.05.2012 15:49 schrieb "James Ots" <m...@jamesots.com>:
>
> isNotEmpty?

Please read the thread again.
This would be counterproductive to the
OP's request and intention.

>>> hasContent
>>> hasItems
>>> hasData

The opposite of isEmpty is isFilled IMHO. As this is unusual in regard to current languages' APIs, I prefer hasData.

[mythz]

My 2c

hasValue
hasItems
notEmpty

[Matthew Butler]

I know Ruby has a similar method, called any? in which it checks to see if an array contains any values. The catch however with that particular function is that an array of null's returns false. so [].any? == false; [nil, 1].any? == true; [nil, nil].any? == false; Which differs from a pure 'not empty' in that.

The issue I have with the 'hasXXXX' is that, to me it sounds like the method should accept an argument to check if a list, map, etc contain that specific argument. isXXX (ie, isEmpty, isNotEmpty, etc) seems to ask if an object is something. A state of being. The 'has' method is asking if it contains a possession (an argument passed to it).

The OP's original request didn't seem to be about using a 'has' notation, but rather avoiding the negation at the beginning of a line, instead the method name itself, particularly when dealing with chains. At least that's how I read it. David would be best to clarify that point. But that being the case, and my points of being something as opposed to containing something (is vs has) I think the isNotEmpty would be a valid syntax while maintaining clarity.

ie:

if( foo().bar().x().list().isNotEmpty() ) .... 

As it makes it clear that we're specifically looking that the last call is checking to if the list is populated in some way, as opposed to negating the beginning of the chain

Matt

[Josh Gargus]

I don't think that isNotEmpty() is contrary to the spirit of the original post.

As the original post says, you read

    !foo.bar().baz().isEmpty()

as "if not foo-bar-baz has no elements",  but isNotEmpty() is different... you would read

    foo.bar().baz().isNotEmpty()

as "if foo-bar-baz is not empty" or "if foo-bar-baz has elements".

Looking at it another way, the important aspect is how easy it is to scan left-to-right, and not whether it is a positive or double-negative.

With regard to some of the other "positive" suggestions ;-)...

I don't like hasContent() and hasData() because they're something that you might ask something that holds zero or one items.

hasElements(), hasItems() don't have this issue, but then you might ask yourself "what kind of Elements/Items are we talking about here?".  Maybe hasObjects() is better, but it still feels unwieldy.

I think the problem comes down to English not having a precise synonym for not-empty.  Therefore, we should say what we mean: isNotEmpty().

Just my two cents, of  course.

Cheers,

Josh

[Josh Gargus]

On Fri May 11 10:37:06 GMT-700 2012, mythz <demis....@gmail.com> wrote: 

My 2c

hasValue
hasItems
notEmpty

Ah, now I change my vote from isNotEmpty() to notEmpty()... same meaning but more concise.

Cheers,

Josh 

[David Morgan ☯]

The comment about any? made me check the Dart interfaces again.

Based on some(bool) ... how about just some()?

if (foo.bar.baz.some()) { ... }

It's definitely on the vague side, but I could be persuaded that "some" means "not none". And it fits with what's already there.

Cheers

David

[William Hesse]

To me, the English synonym for not-empty is nonempty. The advantage
is that isNonempty() has only one capitalization (for typing speed),
the capital letter is different (N rather than I).

But perhaps nonempty is not known well to non-native speakers.

--
William Hesse
Software Engineer
whe...@google.com

Google Denmark ApS
Frederiksborggade 20B, 1 sal
1360 København K
Denmark

CVR nr. 28 86 69 84

If you received this communication by mistake, please don't forward it
to anyone else (it may contain confidential or privileged
information), please erase all copies of it, including all
attachments, and please let the sender know it went to the wrong
person. Thanks.

[Dirk Detering]

Am 12.05.2012 12:33 schrieb "William Hesse" <whe...@google.com>:
>
> To me, the English synonym for not-empty is nonempty.  The advantage
> is that isNonempty() has only one capitalization (for typing speed),
> the capital letter is different (N rather than I).
>
> But perhaps nonempty is not known well to non-native speakers.

Beside that, I'm in doubt that any word that does not explicitly declare the state without applying a negation (like is the case with 'if' and 'unless') would really gain anything here.

I consider expressions like foo.bar.baz.whatelse.isEmpty a design flaw anyway, as it contradicts the Law of Demeter, so the argument of ! being too far away doesn't hold IMO.

--
Det

[Colm Sloan]

collection.any() sounds best. To me, collection.some() implies continuity. It feels like the difference between "do you have any loaves of bread?" and "do you have any breads?", if you know what I mean. However, the point about ruby using any() to mean something slightly different ( http://ruby-doc.org/core-1.9.3/Enumerable.html#method-i-any-3F ) does weaken the any() choice. I think we might have to stick with collection.size > 0 etc.

[Luke Church]

There is a major advantage in grouping together all of the properties of an element into 'is.......' foo. It means that users searching for the things in the API using a code completion UI, only have to type in 'is' and are given a list of things that they can query. I.e. it improves discoverability, one of the most important properties of an API.

If we want to change _all_ the apis properties to 'has' that might be plausible, but I would need convincing of the advantage ;-) But having a consistent name grouping for properties like this is something I would be very sorry to loose, and so would our users :)

Luke

[David Morgan ☯]

That's a good general principle, but I don't think it really applies here:

 + Collection is an interface everyone will learn by heart

 + There's only one "is" method in Collection, and it's the one I'm complaining about ;)

 + List, Queue, etc, don't add any more "is" methods 

At this point though my preference would be to build on some(bool f()) and add some().

As is you could write some(any()) instead of !___.isEmpty() and it would be marginally more readable ;)

Cheers

David

[Sam McCall]

My votes (yes, I know this isn't a poll):

* I'm happy with isEmpty, I check for emptiness about as often as
for non-emptiness, and it's familiar coming from Java (like most of
Collections).

* My preferred name for the opposite method or getter is hasItems(),
with Item being used throughout Collections rather than Element.

* Green is a classic colour for a shed and looks good with most bikes.

[Jay Young]

When I see a collection method named "any", I immediately think of a functional-style method (filter, reduce, map, some, etc).  I don't know if "any" is a common name used in this context, but that's where my mind goes when I see it.  To me, it just doesn't come across as an intuitive name of a method that asks whether a collection contains items.

[Sam McCall]

Jay: I assume that's the idea; any([bool condition(x) = (x) => true])
That's certainly how any? works is ruby (though I didn't know about the default value, I just use .empty?).

[Bob Nystrom]

Just for kicks, here's my opinions:

1. I'm comfortable with "isEmpty". It's familiar and its meaning is pretty obvious. I prefer operations that return bools to be named with "is" when it makes sense.

2. I agree that "!foo.bar.baz.isEmpty" reads a bit funny, but I think this may just be a case where English is making things a bit hard on us and we have to do the best with what we have. If there was a common idiomatic English phrase that mean "is there anything in this" I'd be all about it, but I don't think there is.

3. "hasData" and "hasElements" are good attempts but I feel like "elements" and "data" are just null words here (especially "data") that don't carry a lot of meaning.

4. I like the idea of making the predicate optional in any() and/or some() but I worry that will cause people to stumble into the getter/method distinction. I think users expect things like isEmpty to be getters (like length is).

- bob

[Sam McCall]

On Mon, May 14, 2012 at 7:07 PM, Bob Nystrom <rnys...@google.com> wrote:
> 4. I like the idea of making the predicate optional in any() and/or some()
> but I worry that will cause people to stumble into the getter/method
> distinction. I think users expect things like isEmpty to be getters (like
> length is).

The solution is clearly to add operator call, and boolean coercion...

(But yeah, this is a problem. I still think the optional predicate is
a good solution for a Collection.findFirst() method, but emptiness is
definitely property-ish)

[Christopher Wright]

I might reasonably submit Microsoft's solution for comparison:

http://msdn.microsoft.com/en-us/library/bb337697.aspx

Basically:

if (list.Any(x => f(x))) { ... }

but with the predicate defaulting to `x => true`.

[Sam McCall]

On Mon, May 14, 2012 at 7:15 PM, Christopher Wright <dhas...@google.com> wrote:

I might reasonably submit Microsoft's solution for comparison:

http://msdn.microsoft.com/en-us/library/bb337697.aspx

Basically:

if (list.Any(x => f(x))) { ... }

but with the predicate defaulting to `x => true`.

I think that's what were talking about, but Bob points out that people will write

if (list.any)

because it's "obviously" a property, and trigger closurization by mistake.

[David]

> > 4. I like the idea of making the predicate optional in any() and/or some()
> > but I worry that will cause people to stumble into the getter/method
> > distinction. I think users expect things like isEmpty to be getters (like
> > length is).
>
> The solution is clearly to add operator call, and boolean coercion...

Of course this is how many scripting languages behave.

They put ease of writing code first, and they end up with
"hasElements" (or whatever) being so important that it's the default.

I think that underlines how it's a strange thing to omit from the
interface.

Cheers

David

[David Morgan ☯]

Added http://code.google.com/p/dart/issues/detail?id=3074 which links back to this thread.