Re: [really patch] Re: HashMap putAll/putAllInternal bug

[Stuart Ballard]

David Holmes wrote:
> If you extend AbstractMap (why on earth would you with this
> specialised implementation?) then size is defined as
> entrySet().size(). From what you wrote it would appear that
> entrySet().size() in your case will be a function of the size of the
> front and back entrysets. Even if these are modified outside of the
> main map, as long as it's not concurrent (in which case you're on your
> own), then you should still be able to calculate the map size if the
> front and back maps maintain their size correctly.


Sure, I can calculate the size. The problem is that doing so requires a 
full iteration over the elements of both sets: you can't just sum the 
sizes, because you have to correctly account for elements that are in 
both sets.

That makes this "optimization" of just looping size() times actually a 
pessimization, because you have to iterate over the elements twice 
instead of once. I didn't provide a correct implementation of size() for 
exactly this reason: I was afraid that it would get called a lot on the 
assumption that it's fast, when it's not.

As for why I need this implementation: it's being used for a language 
interpreter and provides an implementation of nested scoping of 
variables. Performance is important because it gets used a LOT. I wanted 
to make sure that creating a new scope was cheap and didn't affect the 
parent scope (it does caching to make sure that gets are cheap too). The 
reasons why both the front and back scope need to be able to change 
directly are complicated but (as far as I've found so far) unavoidable.


> If you can't provide a valid implementation for any concrete method
> that you are supposed to implement, then it seems quite unreasonable
> of you to expect any inherited methods to work for you. I think it
> quite reasonable for a method like putAll to expect to be able to use
> any of the non-optional methods of Map/Set/Iterator to do its job -
> even if it doesn't document exactly which methods it uses.

True, except that I would think it's reasonable to expect the 
implementations to be optimized for the general case, not under a 
mistaken assumption that size() is fast. If I were to provide a correct 
implementation of size(), I'd be even more concerned about this issue 
because then it would be an important performance problem that would be 
really hard to diagnose.

Stuart.

--
Stuart Ballard, Senior Web Developer
FASTNET - Web Solutions
(215) 283-2300, ext. 126
www.fast.net