Original comment posted by kevinb9n on 2009-08-11 at 01:26 PM

getFirst(Iterator<T>, T defaultValue) is the only version of this that's worth
having, as without a default, you're better off just calling
theIterable.iterator().next().

Original comment posted by sebastian.jancke on 2009-08-12 at 07:20 AM

as without a default, you're better off just calling
theIterable.iterator().next().

Calling iterable.iterator().next() is simply not readable - sorry. It is failing in
the same way as most of the JDK collection libraries fail (too low level, missing
readability, ...).

Original comment posted by sebastian.jancke on 2009-08-12 at 07:24 AM

Another issue about this: consistency. There is getLast(iterable/iterator). Either
you break the API to getLast(.., default) or you have to be consistent with getFirst.

Original comment posted by kevinb9n on 2009-08-12 at 05:01 PM

I couldn't disagree more on either count.

iterable.iterator().next() is perfectly clear and readable and unambiguous. I know
exactly what it does, whereas with Iterators.getFirst(), I have to run off and look
up how that library designer decided to do it.

Also, your notion of consistency is deeply misguided. We use consistency in how we
present important functionality, but we never use it to justify adding worthless
functionality, and you shouldn't in your own libraries either!

Original comment posted by kevinb9n on 2009-08-12 at 05:55 PM

(No comment entered for this change.)

Status: Accepted
Labels: post-1.0

Original comment posted by sebastian.jancke on 2009-08-14 at 08:37 AM

To me and collegues, "iterable.iterator().next()" is not readable. It says: "give me
an iterator and then the next element, that is the first". That does not comply with
the sense of readability stated by RC Martin and others. It is not ambigous, you are
right. But "getFirst" states clearly what it does - retrieving the first element.

I agree on not adding worthless functionality. Maybe highest readability is not a
design goal of this library (I do not judge such a decision...)?

Still, having getFirst ist consistent with having getLast. It was the first thing I
noticed and missed, when using getLast on a collection. Maybe it's because I'm used
to it from .NET/LINQ code. There you have a whole bunch of clearly readabily
high-level functions on collections - getFirst is one of them and lot's of others are
already part of this library.

In the end - It was just a suggestion and expression of my experience with this very
nice library. I won't comment more on this, maybe you implement it or you decide not
to - both is ok (as I can still add getFirst through AJ).

Original comment posted by jim.andreou on 2009-08-14 at 10:08 AM

.iterator().next() is a extremely well-established java idiom, since it is the only way
to get the first element of a Collection or a Set for at least a decade now. So
"readability" concerns are really moot, except for perhaps very recent/inexperienced
java developers (who are clearly not the target audience of this library). Coming by
2009 and introducing a longer version of something as common and which works perfectly
would be a very strange decision for google collections.

Original comment posted by kevinb9n on 2009-09-17 at 05:01 PM

(No comment entered for this change.)

Original comment posted by kevinb9n on 2009-09-17 at 05:45 PM

(No comment entered for this change.)

Labels: -post-1.0, Milestone-Post1.0

Original comment posted by kevinb9n on 2009-09-17 at 05:57 PM

(No comment entered for this change.)

Labels: Type-Enhancement

Original comment posted by kevinb@google.com on 2010-03-16 at 08:04 PM

I don't think I ever made it clear: I believe we should add an overload accepting a
"T defaultValue" to each Itera*s method we currently have that accepts an Iterable<T>,
returns a T, and throws an exception if no suitable T is found. However many methods
that is.

Original comment posted by kevinb@google.com on 2010-07-30 at 03:50 AM

(No comment entered for this change.)

Labels: Milestone-Release07

Original comment posted by kevinb@google.com on 2010-08-30 at 05:33 PM

Looks like we've done this get, getLast and getOnlyElement but just need to do it for find and we're done.

Original comment posted by kevinb@google.com on 2010-08-30 at 05:39 PM

Wait, no, we never did the first part of this which is to add getFirst(Iter, T).

And forget what I said about find(), because that's tracked in bug 150. That's a little weird but that's how it is so let's just keep it that way.

Original comment posted by boppenheim@google.com on 2010-08-30 at 05:59 PM

(No comment entered for this change.)

Owner: boppenh...@google.com

Original comment posted by boppenheim@google.com on 2010-09-04 at 05:38 AM

Committed in r105.

Status: Fixed

Original comment posted by ogregoire on 2010-11-23 at 02:38 PM

Please reconsider adding Itera_s.getFirst/getNext(Itera_ i)

For Iterables, the following methods exist:

• public static <T> T get(Iterable<T> i, int p)
• public static <T> T get(Iterable<T> i, int p, T defVal)
• public static <T> T getFirst(Iterable<T> i, T defVal)
• public static <T> T getLast(Iterable<T> i)
• public static <T> T getLast(Iterable<T> i, T defVal)
• public static <T> T getOnlyElement(Iterable<T> i)
• public static <T> T getOnlyElement(Iterable<T> i, T defVal)

It really looks like something is missing.

My colleagues who just start Java keep bugging me about the fact that iterator().next() is just not understandable at first sight.

Original comment posted by ori.schwartz on 2011-12-22 at 08:43 PM

Can we also add a checked version Iterables#getFirst that takes no default value and throws a NoSuchElementException?

It would work exactly like Iterables.getLast(T).

I often write Iterables.getFirst(it, null) and then check for null.

Original comment posted by ipremraj11 on 2011-12-24 at 10:01 AM

It's already mentioned that you need to call - iterable.iterator().next()(which will throw NoSuchElementException) than Iterables.getFirst(it, null) and then check for null.

Original comment posted by mar...@aie.pl on 2013-05-16 at 08:09 PM

How about returning an Optional on getFirst?

public static <T> Optional<T> getFirst(Iterable<T> i)

Original comment posted by kevinb@google.com on 2013-05-22 at 04:22 AM

We did that for FluentIterable. I doubt it's worth going back and fixing Iterables now. Use FluentIterable!