It's fairly straightforward to prohibit modifications via the attributes methods ... just override ContextBase and make methods like put() and remove() throw UnsupportedOperationException instead of doing the processing. You'd also want to review the objects returned by entrySet(), which also allow modifications in the default implementation.
I would strongly suggest that you do *not* disable the get() method -- even though you can by using the same technique. The basic idea is that you should be able to write commands that can operate on a Context object provided by anyone, without having to cast to a particular implementation class or interface. Disabling get() means that you'll need to bind the APIs of the Command objects solely to the API of your Context object, thereby reducing your flexibility. Craig On Tue, 23 Nov 2004 17:12:55 +0100, Eric Pugh <[EMAIL PROTECTED]> wrote: > 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]
