Craig R. McClanahan wrote:
We haven't released anything yet ... why not just check it in to the o.a.c.c.impl package so we can all take a look. We need to completely fulfill the Map contracts if we go this way, and I have some concerns about that.
It's there. This one just delegates the Map methods to getAttributes, so the Context object can be used in places that already expect a Map.
OK, I can buy into Context is-a Map. Here's one way to approach making this change:
* Context becomes a marker interface:
public interface Context extends Map { }
The getAttributes() method is removed.
* In order to fulfill the Map contract for things like equals() and hashCode()
more directly, ContextBase can extend HashMap instead of implement Map
with a delegated-to HashMap instance variable like ContextBaseAttributes
does now.
* For the property transparency thing:
- In the ContextBase constructor, introspect the list of properties, and add key-value pairs for all of them to the superclass Map. The values in this case are actually irrelevant, because they won't be used -- all the accessors will need to know to call the underlying property getter/setter.
- get() and put() call the right getter or setter, which can be implemented
however they want (I don't see any reason they should want to store
the values in the superclass HashMap, but they could by just calling
super.get() and super.put()).
- If a user attempts to remove() the key corresponding to a property, throw IllegalArgumentException.
Doing things this way means we don't need getField()/putField() to accomplish your desire to (optionally) keep all the values in the internal map.
Does this sound like a reasonable strategy?
-T.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
