----- Original Message ----- From: "Michael A. Smith" <[EMAIL PROTECTED]> To: "Morgan Delagrange" <[EMAIL PROTECTED]> Cc: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Thursday, March 21, 2002 1:26 PM Subject: Re: [Collections] non-compatible changes
> 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. > > > 5. DoubleOrderedMap requires its keys and elements to be comparable. I > > > don't think the external API relies on Comparable (just the internal API), > > > so I don't think this must be fixed before a 2.0 release, but I didn't > > > look quite that closely to know for sure. > > > > > > 6. The following classes have "protected" members and/or methods, but > > > the ability to subclass without "corrupting" the internal state of > > > the parent class is suspect: BeanMap, FastArrayList, FastHashMap, > > > FastTreeMap. Fixing these would probably involve making some fields > > > private. > > > > -1. We should minimize changes that affect Serialization, and in this case > > it doesn't seem worth the price. > > I don't know how either of these have effects on Serialization. > > DoubleOrderedMap isn't serializable, and even if it was, it doesn't have > any Comparable fields that would be serialized (all the Comparable > references are casts in order to do a comparison). I didn't mean to refer to #5, since you aren't proposing any changes. > As for changing protected members to private or otherwise adjusting to > ensure subclasses can't corrupt internal structures, that doesn't change > serialization either. If anything, it just requires the addition of a > serialVersionUID to say "yes, this class really does have the same > fields". If you take care to preserve Serialization, that would be a plus. (I'm far from the world's expert on Serialization :) But what about existing subclasses? I cannot say with certainty that such subclasses do not exist and do not rely on methods we currently expose. We can insert warnings in the Javadocs, but changing the interface seems premature. > > regards, > michael > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
