commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Sgarlata" <matt.sgarl...@spiderstrategies.com>
Subject Re: [VOTE] Release Chain 1.0
Date Tue, 23 Nov 2004 17:24:30 GMT
Thanks for the info Eric.  I agree, it's much better to expose a simpler 
interface and then write a single implementation that can expose that simple 
interface as a Map.  Otherwise, you're forcing each and every subclass to 
implement Map, which is a huge pain.  Of course ContextBase does this, but 
it's better not to force an abstract class on the implementers of an 
interface... that way existing classes can easily be made to implement the 
interface without unduly polluting their implementation with random methods 
that will hardly be used, like entrySet()

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" <epugh@upstate.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>; 
"Martin Cooper" <mfncooper@gmail.com>
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:mfncooper@gmail.com]
>> 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
>> <simon@ecnetwork.co.nz> 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: commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message