Comments (21)
Yay for minimal constructors. Yay for not supporting varargs creation.
One taste question (danger: bikeshed discussion looming) about the static
creation
methods; how do we feel about more evocative names than "newInstance"? You say
that
it is important to name #4 differently, but might it be desirable to name #3
differently? Or #2?
SnazzyMap.withBlort(37);
SnazzyMap.fromMap(fooMap);
Original comment by [email protected]
on 31 Oct 2007 at 9:05
from google-collections.
In general, this seems like a good idea. however, you should make sure that
you do
not screw up things people may want to do via reflection (for introspective
apis and
the like). obviously you should have a public noargs constructor, but the copy
constructor is also one i could see reflective code depending on.
Original comment by [email protected]
on 1 Nov 2007 at 2:12
from google-collections.
No, I believe it's highly illegitimate for any code to depend on the presence
of a
particular public constructor beyond the parameterless one.
Original comment by [email protected]
on 1 Nov 2007 at 9:55
from google-collections.
hilsdale: on the naming issue, I like your suggestions. It would be nice to
know what
is going to end up happening in the JDK; if there is going to be
HashMap.newInstance() then we may as well just get with that program now. ONE
of the
places where this JDK issue is tracked is here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5092426
Original comment by [email protected]
on 1 Nov 2007 at 11:22
from google-collections.
I agree with hilsdale on naming. Methods with names like "newInstance" should
be
used only when we genuinely cannot come up with something more meaningful (and I
suspect this will be rare).
Original comment by [email protected]
on 12 Mar 2008 at 6:17
from google-collections.
Original comment by [email protected]
on 27 May 2008 at 6:30
- Added labels: 1.0
from google-collections.
First just let me say, fantastic framework.
Now my question is, why are there not "new" methods for the Multisets class? For
example I can do something like the following to create a new HashSet:
Set<String> stringSet = Sets.newHashSet();
but I can't do something like the following to create a new Multiset:
Multiset<String> stringBag = Multisets.newHashMultiset();
instead I have to use the factory method in HashMultiset called create() to get
a new
instance of a HashMultiset. Seems like you should be consistent throughout your
api,
e.g. either use create() methods or "new" methods. I prefer the "new" methods
but I'm
sure you can juggle the pros and cons.
Thanks for your time and again, fantastic work!
Original comment by [email protected]
on 17 Feb 2009 at 12:37
from google-collections.
This question of where to locate all the factory methods has two main solutions
and
both are correct. We had to choose one. We decided to consistently put the
methods
on the implementation class whenever possible (ie, when it's our own
implementation
class), and fall back on kitchen-sink utility classes like Sets only when
necessary
(because it's a JDK implementation class).
Original comment by [email protected]
on 26 Feb 2009 at 5:00
from google-collections.
Issue 112 has been merged into this issue.
Original comment by [email protected]
on 26 Feb 2009 at 5:01
from google-collections.
Kevin, by this rule of consistency it follows that ArrayListMultimap,
LinkedListMultimap etc, should have had a create() method instead of falling
back to
Multimaps utility methods. So, can you elaborate a bit on this particular
apparent
discrepancy?
Original comment by jim.andreou
on 26 Feb 2009 at 5:43
from google-collections.
Fixing the Multimap factory methods has been on my to-do list for a while, but
I've
been busy with other stuff. We'll deal with it before the next release.
Original comment by [email protected]
on 26 Feb 2009 at 6:28
from google-collections.
We are sooooo close now. Just need CustomFooMultimap.create() to replace
Multimaps.newFooMultimap() and I think we're done!!
Original comment by [email protected]
on 24 Mar 2009 at 10:09
from google-collections.
The LinkedListMultimap API docs have an incorrect example for instantiation.
The
class header still shows the use of a standard constructor, when that
constructor is
not publicly visible.
http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?http://goo
gle-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/packa
ge-summary.html
{{{
Multimap<K, V> multimap = new LinkedListMultimap<K, V>();
}}}
Original comment by [email protected]
on 8 Apr 2009 at 6:37
from google-collections.
Thanks, I'll fix that.
Original comment by [email protected]
on 8 Apr 2009 at 7:34
from google-collections.
I like the factory methods. One case where I am having difficulty is with
synchronized wrappers. E.g. I'd like to create a synchronized SetMultimap in
one
line.
This would be great, but compiler complains:
private final SetMultimap<String, String> map =
Multimaps.synchronizedSetMultimap(HashMultimap.create());
I have to make in intermediate reference to the unsynchronized map:
private <K, V> SetMultimap<K, V> createSynchronizedSetMultimap() {
SetMultimap<K, V> unsynchronized = HashMultimap.create();
return Multimaps.synchronizedSetMultimap(unsynchronized);
}
Original comment by [email protected]
on 14 Apr 2009 at 1:04
from google-collections.
The following single-line command does what you want.
private final SetMultimap<String, String> map =
Multimaps.synchronizedSetMultimap(HashMultimap.<String, String>create());
The generics-after-the-dot syntax looks a little strange, but it works.
Original comment by [email protected]
on 14 Apr 2009 at 1:29
from google-collections.
The lack of a no-arg constructor for classes like HashMultimap is a serious
problem
for any use of reflection. Its a colossal pain if you're using hibernate, for
example. Following the constructor pattern of the standard collections would
make far
more sense than static factory methods.
Original comment by [email protected]
on 4 May 2009 at 10:30
from google-collections.
I agree with Chris Surridge. This just hit me with HashMultiset. This began
with
Kevin saying, "I propose that we keep constructors to a minimum, possibly
having any
constructors besides the parameterless one being private." But how did that
turn into
"no public constructors at all", not even parameterless?
Original comment by [email protected]
on 27 Jun 2009 at 12:34
from google-collections.
Original comment by [email protected]
on 17 Sep 2009 at 5:45
- Added labels: Milestone-1.0
from google-collections.
Original comment by [email protected]
on 17 Sep 2009 at 5:46
- Removed labels: 1.0
from google-collections.
The request for constructors was filed in issue 160.
The work described in this bug record is complete except for
Multimaps.new*Multimap().
We have decided to just live with this inconsistency. In the future, it's
likely those
methods will become deprecated, and everyone will have maybe two years in which
to get
their code fixed to the newer, better API.
Original comment by [email protected]
on 18 Sep 2009 at 4:49
- 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.