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. > > 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). 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". regards, michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
