Get rid of the ForwardingMap.create* methods, and view-collection fields

[GoogleCodeExporter]

And so forth. Check for this consistency in all forwarding collections.

Original issue reported on code.google.com by kevin...@gmail.com on 17 Sep 2009 at 6:42

[GoogleCodeExporter]

jared said (I'm agnostic):

Actually, I think we should remove the create* methods from ForwardingMap, as 
Matt 
suggests.

That way, the Forwarding* classes forward and do nothing else, which is more 
intuitive. Also, we avoid adding three member variables to every ForwardingMap 
instance, even though they're redundant in many implementations.

While that's a little inconvenient for people who are currently using the 
ForwardingMap.create* methods, it follows the "when in doubt, leave it out" 
principle.

Original comment by kevin...@gmail.com on 12 Oct 2009 at 6:17

[GoogleCodeExporter]

Thinking about this, I've realized that none of the similar methods in 
ForwardingMultiset (entrySet, elementSet) or ForwardingMultimap (four of them) 
are 
doing this, so we have a big inconsistency that has to get resolved one way or 
the 
other.

It also looks like ForwardingMap got these fields in a somewhat accidental 
manner.

So it seems like a good idea to back out of this, although how exactly to do it 
in 
the least disruptive manner is an open question.

Original comment by kevin...@gmail.com on 16 Oct 2009 at 10:46

• Changed title: Get rid of the ForwardingMap.create* methods, and view-collection fields
• Added labels: Type-Defect
• Removed labels: Type-Docs

[GoogleCodeExporter]

unassigning because I'm not working on this.

I still think it should get done for 1.0 if possible.

Original comment by kevin...@gmail.com on 29 Oct 2009 at 6:43

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 30 Oct 2009 at 6:45

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 2 Nov 2009 at 10:16

• Changed state: Fixed