> > // Creates a Set backed by the given map. Given > > // map must be empty. > > public static Set createSet(Map map); > > > > public static SortedSet createSortedSet(SortedMap map); > > This kind of depends on how a Set is backed by a Map. (You'll have to > forgive me for not knowing how this works.) For example, in a WeakHashMap, > it is the keys that are held with weak references. If while backing the Set > with this Map, the Set's values are stored in the Map's values and not its > keys, then it may not work as expected. If it works as expected, I have no > objection to this.
The map-to-set wrapper would have to use the map's keys as the set's elements, as values in a map are not guaranteed to be unique. The WeakHashMap javadoc specifies that it uses "weak keys", so it should work correctly with such a set wrapper. > So maybe what I really need to do is write a "weak reference Set wrapper," > and encapsulate whatever Set the user passes. Basically, doing something > similar to your Transformers and Predicates, that wrap underlying > collections. Perhaps the natural extension is to go to Lists, etc. as you > are discussing with Transformers and Predicates. As long as the public API is static wrapper methods for each of the implementations (as per the java.util.Collections.synchronized methods) I'm fine with this. Although it really does feel like we could provide some sort of Transformer- based approach that would enable weak elements but also other functionality... Like...Before I mentioned a two-transformer approach. If the "read" transformer (which would transform weak references back into their referents before returning the value from the collection) emptied the reference queue before returning results, the two-transformer approach would probably work. > Which brings me to another thought - Ultimately, this "weak reference > Collection wrapper," Transformers and Predicates are all collection wrappers > of one sort or another that encapsulate another collection that actually > stores the objects (or another wrapper). Perhaps they should all subclass > from the same class, or implement a common interface? There already exists a "ProxyMap" class for this purpose for Maps, and there's been talk of including "ProxyList", "ProxySet" etc. My feeling is if you want to code them up, they'd be accepted. -Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
