--- On Fri, 9/10/10, Adam Heath <[email protected]> wrote:
> On 09/10/2010 01:03 PM, Adrian Crum
> wrote:
> > --- On Fri, 9/10/10, Adam Heath<[email protected]>
> wrote:
> >> I haven't had this be a problem for
> >> me in production anywhere, but I noticed that
> when
> >> remove(Object) is called, it'll remove the value
> from the
> >> top-most map in the stack. This then means
> any queries
> >> for the key will fall-thru to lower maps, which
> is
> >> definately *not* what should occur.
> >
> > That would depend on your point of view. From a
> variable scoping viewpoint, that would be the correct
> behavior.
> >
> > Let's say I have two variables, both with the same
> name. One is declared early on and could be considered
> "global." The other is declared inside a method and is
> considered "local." If I remove the local variable, I would
> expect the global variable to still be there.
>
> java.util.Map.remove(Object) says that it removes the
> object from the
> map, such that Map.containsKey(Object) will return false
> afterwards.
> That is what the contract states, and that's what
> MapStack/MapContext
> should follow.
>
> If you want another method to do what you say, then I can
> go ahead and
> implement that.
>
> As it is, if an instance of MapStack/MapContext is passed
> to legacy
> code that only deals with maps, then it'll break.
Like I said, it's a matter of perspective. What is MapStack's purpose - to
implement a Map, or to implement variable scoping? Based on the MapStack code
and how it is used in the framework, I think it is the latter.
It would be helpful to hear from others.
> >> Additionally, entrySet() returns an unmodifiable
> Collection
> >> of Map.Entry. However, those entries point
> to the
> >> *original* map. If someone called setValue()
> on the
> >> entry, it would modify the original map, instead
> of
> >> inserting a value into the top-most map.
> >
> > Huh? How can you modify an unmodifiable collection? If
> that's possible, then my recommendation would be to enforce
> the unmodifiable part and not worry about which scope is
> being changed.
>
> You're not modifying the collection. You're modifying
> a value *in*
> the collection. Collections.unmodifiableFoo only
> protects the collection.
>
> Collection.iterator().next().setValue("foo") should place
> an override
> entry into the top-level map, and then change the entry
> instance
> that's in the underlying protected read-only collection.
If it's truly unmodifiable, Collection.iterator().next().setValue("foo") should
throw an exception. In other words, the MapStack should be wrapped with an
unmodifiable Map, and then return an entry set from the unmodifiable Map, or
implement unmodifiable Map.Entry.
-Adrian
