I actually already decided to take that approach you suggest in the Morph framework :-) I just updated the site in case you'd like to see.
http://www.crystalcognition.com/sgarlatm/morph
Specifically, this is what I added:
- I created the net.sf.morph.context.ContextMapBridge which makes exposing a Context as a Map easy. The ContextMapBridge knows about HierarchicalContexts and automaticallly makes the Map implementation expose ancestor context information.
- I made net.sf.morph.context.BaseContext implement both Context and Map (by delegating to ContextMapBridge), so if you extend from this class, the Context you use will implement both Context and Map. All contexts implemented in Morph will extend from BaseContext, so every Context implementation provided by Morph will implement both Context and Map.
- net.sf.morph.context.ContextMap is a wrapper around any Context implementation that exposes that Context as a Map. Example: Map map = new ContextMap(myContext);
- net.sf.morph.context.contexts.MapContext is a simple Context implementation that is internally backed by a Map. If you want an empty Context, then you would say Context context = new MapContext();
Matt
PS - I stole Chain's MapEntry class and included a copy in Morph to minimize dependencies. The Morph core is dependent only on Commons Logging, and I intend to keep it that way.
----- Original Message ----- From: "Eric Pugh" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Martin Cooper" <[EMAIL PROTECTED]>
Sent: Tuesday, November 23, 2004 11:12 AM
Subject: RE: [VOTE] Release Chain 1.0
We had a similar discussion over in [configuration] prior to 1.0 over having
the Configuration interface extend Map. It was great because you could do
all sorts of cool tricks with passing configurations into things expecting
Maps and still have the code work. Or, an existing application that dealt
with a Map of configuration parameters would work seamlessly with the Map
derived configuration. However, at the end of it, we felt like it ended up
polluting Configuration, adding extra methods that didn't always map to the
underlying implementation. So we ended up keeping Configuration the way it
was and adding a MapConfiguration that did extend Map.
Could a similar approach work for Context? Provide a standard Context and then a MapContext sub interface that exposes the Map interface? In my use of Chain I haven't had a situation where I needed the extra Map provided methods like keySet or entrySet. But, if I did, I could just cast to MapContext and then get them..
The other reason I wouldn't mind having Context NOT extend Map is that when
I implement my own Context, I don't want user's directly putting and getting
stuff into the context via the Map put and get methods. I want them to use
my accessors ONLY.
At any rate, I've been using Chain for a couple days now in my project, and
am very happy to be replacing my own code with Chain!
Eric
-----Original Message----- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, November 22, 2004 10:14 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release Chain 1.0
On Tue, 23 Nov 2004 09:37:27 +1300, Simon Kitching
<[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On Mon, 2004-11-22 at 20:39, Martin Cooper wrote:
> > This sounds like an enhancement request to me. Are you really
> > suggesting that Chain should not be released until your specific
> > enhancement is endorsed and incorporated into the component? I'm
> > afraid I, for one, can't sign up for that.
>
> I think Matt's comment was entirely reasonable. The whole point of a > 1.0
> release is to "freeze" the API. If the API isn't right, then people
> certainly should speak up *before* the API freeze.
You're right, of course.
> Of course it is better to speak up well before then if possible, but a
> release proposal is bound to prompt people to get around to voicing > that
> concern they have had kicking around in the back of their mind for a
> while. Anyone raising the prospect of a release should be expecting > this
> sort of thing.
I was (over)reacting to exactly that. Chain was promoted out of the sandbox almost 6 months ago, so seeing such a fundamental change being proposed at this point was a bit like a bolt from the blue.
Matt, I apologise for jumping down your throat.
> It looks to me, as an outsider, like the concensus is that the existing > interface *is* ok, but as a commons committer I hope that everyone will > give it serious consideration, and not ignore it as "too late". It is > perfectly valid to change APIs before 1.0 (keeping compatibility is > *desirable* but not mandatory). It's certainly better than being stuck > with the wrong API post-1.0.
Agreed. I have first hand experience of dealing with a poor API being exposed in a release...
-- Martin Cooper
> Regards, > > Simon > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
