Factroy-Method to create a FluentIterable from an array

[GoogleCodeExporter]

I think it would be nice to be able to create a FluentIterable from an array 
directly, with a factory method like this:
FluentIterable.from(E... elements) or FluentIterable.from(E[] elements)

This could simply call Arrays.asList(elements) internally, as I am doing now 
explicitly on the outside.
It is very usefull for working with legacy code or other APIs returning arrays.
Also it feels to be consistent, as there is a "toArray" method; so it would be 
a logical consequence to provide a from(Array) factory method also.

Original issue reported on code.google.com by drothma...@googlemail.com on 17 Jul 2012 at 3:04

[GoogleCodeExporter]

Again, will put on the API review this week.

Original comment by kurt.kluever on 24 Jul 2012 at 5:29

• Changed state: Research

[GoogleCodeExporter]

Yes, I'd like to see such an overload, too.

Original comment by j...@nwsnet.de on 31 Jul 2012 at 10:35

[GoogleCodeExporter]

Are there any news on this, kurt?

Original comment by drothma...@googlemail.com on 21 Aug 2012 at 8:52

[GoogleCodeExporter]

FluentIterable.from(E...) or (E[])
Issues:
varargs suck, but there are lots of internal usages!
Why not just use asList(E...)?  That’s been our go-to pushback argument for 
varargs and array-accepting overloads
Lots of users are using from(Enum.values())
gak to investigate all varargs methods.

Punting over to Greg...

Original comment by kurt.kluever on 21 Aug 2012 at 8:56

[GoogleCodeExporter]

I'm ambivalent.  I'll put it on the docket for our weekly discussion.  

Original comment by gak@google.com on 21 Aug 2012 at 9:06

[GoogleCodeExporter]

Oh, wait.  No.  I'm not.  :-)

I occasionally get lured into thinking that varargs makes sense here, but it 
really doesn't.  It's rare that you have a fixed set of elements that start a 
fluent chain of invocation since it's much more likely that the properties of 
those elements are known.  Immutable*.of() are great for tests, but it'd be 
pretty strange to define test data as a FI.

As for the "working with legacy code" side of it, the clarity that comes from 
explicitly creating an immutable copy or a list view is quite valuable and 
encouraging callers to perform that operation as early as possible seems like a 
good thing too.

Original comment by gak@google.com on 21 Aug 2012 at 9:17

[GoogleCodeExporter]

Aside from `Enum.values()`, the reflection-related methods on class 
(`getMethods()`, `getAnnotations()` etc.) return arrays, and using 
`FluentIterable` to filter for specific elements helps here. Thus, 
`FluentIterable.from(E...)` would make things more concise.

Original comment by j...@nwsnet.de on 10 Jul 2013 at 8:32

[GoogleCodeExporter]

I don't think that there's any disagreement that a method that accepts an array 
would be more concise for callers that are holding a reference to an array.  
Whether that is a sufficient benefit over forcing callers to explicitly copy or 
wrap that array is the question.

FluentIterable.from(Arrays.asList(clazz.getDeclaredMethods()))…
vs
FluentIterable.from(clazz.getDeclaredMethods())

or

FluentIterable.from(EnumSet.allOf(SomeEnum.class))…
vs
FluentIterable.from(SomeEnum.values())

The second versions are definitely more concise, but the cost is pretty minimal 
considering that the available adapters are pretty succinct.

Original comment by gak@google.com on 10 Jul 2013 at 5:39

[GoogleCodeExporter]

Issue 1741 has been merged into this issue.

Original comment by lowas...@google.com on 30 Apr 2014 at 4:58

[GoogleCodeExporter]

I understand there are alternative methods of achieving the same thing; though 
this change implies only a very minimal addition, is there a downside that is 
holding up this bug?  Perhaps some form of discouraging array usage? (though it 
is not always a choice and varargs do have their benefits)

It seems only natural to me for this type of utility to accept both Iterables 
and Arrays as its purpose is mainly to iterate, and thus seems very in-line 
with the for construct.  For arrays to not be supported almost feels like an 
inconsistency.

Original comment by lhunath@lyndir.com on 30 Apr 2014 at 5:14

[GoogleCodeExporter]

FluentIterable.of(E[]) was added in 18.0.

Original comment by cgdecker@google.com on 6 Oct 2014 at 2:21

• Changed state: Fixed
• Added labels: Milestone-Release18

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:14

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit