commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <>
Subject RE: [VOTE] Release Chain 1.0
Date Tue, 23 Nov 2004 16:12:55 GMT
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!


> -----Original Message-----
> From: Martin Cooper []
> 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
> <> 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:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message