Comments (14)
Would be nice to have the other Collection methods lacking for Iterables (like
Iterables.addAll()), e.g. Iterables.containsAll(), removeAll(), retainAll().
Original comment by [email protected]
on 25 Oct 2007 at 2:50
from google-collections.
also merge() of two or more sorted iterators. (we have this internally already).
Original comment by [email protected]
on 5 Nov 2007 at 6:51
from google-collections.
For Iterables, it seems like many of these could be "solved" by presenting a
List
view. Obviously, anyone who called size() or tried to go backward with a
ListIterator would be sorry, but if we can add either asList() (with warnings)
or
size(), elementAt(), randomElement(), contains(), removeFirst(), removeAll(),
truncate(), index(), addAll(), containsAll(), removeAll(), and retainAll(), I
think
it may be worth it.
Are there any obvious problems, other than the fact that it can be misused?
And is
misuse a serious enough problem to abandon it?
Original comment by [email protected]
on 8 Nov 2007 at 7:10
from google-collections.
Damn, you're right! Once again, my brain always seems to forget that List does
not
imply RandomAccess. This will be so much simpler. Brilliant, thanks.
Original comment by [email protected]
on 8 Nov 2007 at 7:29
from google-collections.
I'd like to see added to this list:
drop(Iter, int)
take(Iter, int)
Where "drop" returns another Iterable/ator that is the same as before but skips
the
first "int" values. "take" returns an Iterable/ator that returns up to the
first
"int" values, and is then done. The names "drop" and "take" are from the
Haskell
functions of the same name.
My current use case for "drop" is:
Foo thing = listOfThings.get(0);
for (foo : Iterables.drop(listOfThings, 1)) {
thing = someWeirdActionsWith(thing, foo);
}
That is, I want to do what is essentially reduce/inject/foldl (depending on what
other language you're familiar with), but with the nice syntax that java affords
Iterables.
Original comment by [email protected]
on 8 Nov 2007 at 7:47
from google-collections.
It's not clear to me how I can assign this to myself in the bug tracker, but:
I'm on it.
Original comment by [email protected]
on 8 Nov 2007 at 11:36
from google-collections.
If i understand correctly, you intend on creating a List view for an Iterable
so you
can call, for example, addAll() on a Collection? This is a good idea, however,
i
believe a variety of the collections in the standard jdk call size() on the
incoming
collection, which would sort of negate the usefulness of this view. maybe you
could
create the view with a caller provided approximate size? just something to
think about.
Original comment by [email protected]
on 9 Nov 2007 at 3:08
from google-collections.
A good point. I'd added some documentation to indicate that Iterables.addAll()
is
more appropriate for those cases. (I also have a note explaining that creating
a
"real" List with Lists.newArrayList(Iterable) or Lists.immutableList(Iterable)
is
advisable most of the time.)
I think this is a better approach than having size() return an estimate, since,
for
example, an array-based List's addAll() method might depend on an accurate
return
value from size() to determine its new capacity.
Original comment by [email protected]
on 9 Nov 2007 at 5:06
from google-collections.
Since this is omnibus can I also add:
<E extends Comparable> boolean isSorted(Iterable<E> elements)
and also a version that uses a comparator?
Original comment by [email protected]
on 21 Nov 2007 at 6:55
from google-collections.
This will go onto Ordering, and I believe will also accept varargs. I was
thinking
to call it isIncreasing() and also have isStrictlyIncreasing(); your thoughts?
It does lead to the question of whether Ordering should also provide the
corresponding decreasing methods; it doesn't have to since there is
.reverse().isIncreasing(); but then we do have both min and max.
Original comment by [email protected]
on 21 Nov 2007 at 7:43
from google-collections.
I'm fine with just increasing and not decreasing. Min/max is more common and so
it
makes sense for them to be special.
Not sure but it might be nice to have an easy way to get a natural order
Ordering.
Ordering.forComparator(Comparators.naturalOrder()) seems a little long-winded
for
what I presume is pretty common.
Original comment by [email protected]
on 21 Nov 2007 at 7:55
from google-collections.
Absolutely. At the same time that Ordering itself appears out here in the
open-source code base, the Comparators methods will actually return Orderings
(Ordering implements Comparator). Both these changes have been made internally
already.
Original comment by [email protected]
on 21 Nov 2007 at 8:14
from google-collections.
Itera...s methods just added: size(), isEmpty() limit(), skip(), getLast().
Original comment by [email protected]
on 24 Mar 2008 at 8:27
from google-collections.
Most things described in this entry have been done; most of the remainder are
not
considered important; anything else important that should be done should be
filed as
its own issue.
Original comment by [email protected]
on 17 Mar 2009 at 5:01
- Changed state: Fixed
from google-collections.
Related Issues (20)
- Preconditions.checkArgumentNotNull HOT 2
- MapMaker with weak keys: keySet() doubles reference counts in map HOT 4
- broken checksums in maven artefacts for rc4 HOT 6
- Predicates.equalTo() should return a Predicate<Object> HOT 2
- Make com.google.common.collect.ImmutableCollection.Builder public HOT 3
- Easy way to deal with null Iterables when looping HOT 1
- Please provide Sets.symmetricDifference() HOT 3
- static method Functions.toStringFunction() should be parametrized HOT 5
- LinkedListMultimap values should be of type Deque<V> HOT 3
- add transformEntries method to Maps and SortedMaps HOT 4
- Be consistent with [Collection]s.new*[Collection](...) HOT 3
- CusomConcurrentHashMap.Values should override toArray(T[]) HOT 2
- with/withoutmethods on immutable collections HOT 2
- OutOfMemoryError when using MapMaker and Soft/Weak-Keys/Values HOT 1
- MemoryLeak(?) when using expiration in MapMaker HOT 2
- equals is not implemented for Collections2.filter HOT 1
- Allow asMap() to return a Map which has defined value Collections HOT 1
- GWT Module missing HOT 3
- Create an alternative to commons-collections MultiKey
- Patch for /trunk/testfw/com/google/common/collect/testing/MapInterfaceTest.java
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from google-collections.