commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [Collections] non-compatible changes
Date Fri, 22 Mar 2002 20:33:35 GMT
From: "Morgan Delagrange" <mdelagra@yahoo.com>
> ----- Original Message -----
> From: "Michael A. Smith" <mas@apache.org>
> > On Thu, 21 Mar 2002, Morgan Delagrange wrote:
> > > > 3. BeanMap.values() is modifiable, but modifications are not
reflected
> in
> > > > the BeanMap.  Probably should return an unmodifiable collection.
> > > >
> > > > 4. BeanMap.keySet() is modifiable.  Modifications to it (i.e.
removes)
> > > > will be reflected in the BeanMap, but that's probably not a good
idea.
> > > > Probably should return an unmodifiable collection.
> > >
> > > I'm -1 to these changes.  There may be clients to BeanMap that expect
> this
> > > behaviour, and I'm uncomfortable with changing it in the eleventh hour
> of
> > > the release.  I think that, for now, we should just document the
> behavior in
> > > the Javadocs.
> >
> > So, you'd rather leave the behavior such that changes to keySet() are
> > reflected in the map, entrySet() is unmodifiable, and changes to
values()
> > are not reflected in the map?  Having three different behaviors for
these
> > just seems wrong to me as well.
>
> It's not ideal, but it's a little late in the game to change it.  I've
> updated the documentation to point out this behaviour.  (Also, the fact
that
> changes to the keySet() are reflected by the Map is in keeping with the
> general contract for Map.)
>
> I would be willing to retract my -1 if you got buy-in from James and there
> were no other objections.  However, if we're going to fix it, let's make
it
> agree with the Map contract.  Personally, changing it at this point makes
me
> uncomfortable, and I'd rather not do it.

I kinda agree with you both ;-)

I think ultimately BeanMap should be fixed to truly implement the Map
interface if we can. Though the Collections package is built around the idea
that not all operations need to be supported, so using unmodifiable
collections for keySet() seems to make sense; especially as keys cannot be
removed or added - only values can be updated.

So I'd prefer keySet() to be unmodifiable and values() to be modifiable and
reflected in the Map - if it can't be reflected easily (or until it gets
implemented) then I'd prefer it to be unmodifiable as well for now. Its
better for a feature to not be available than for it to be wrong.

James


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message