commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject RE: [pattern][lang] Cross dependecy
Date Fri, 09 Aug 2002 23:47:12 GMT


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Friday, August 09, 2002 3:46 PM
> To: Jakarta Commons Developers List
> Subject: Re: [pattern][lang] Cross dependecy
> 
> 
> As has been mentioned elsewhere, [lang] is common code, 
> [pattern] is common
> interfaces. At least in theory....
> 
> Currently, [pattern] depends on [lang] for the 
> NestableExceptions and the
> Serialization utilities. These are core to [pattern] 
> functionality. (For
> those unaware, [pattern] contains both the interface and a 
> basic utility
> class. IMO to have just the interface alone would be rather 
> pointless, and
> besides the interface requires the associated exception.)
> 
> So I've had a look at this dependency, and here's my new opinion:
> NestableExceptions are a pattern (class, not interface based)
> Enum is a pattern (class, not interface based)
> Serialization utilities are to do with a pattern interface 
> (Serializable) -
> (not quite sure why I didn't see this earlier...)
> 
> If you do a hypothetical move of Nested Exceptions and 
> Serailization to
> [pattern], you end up with two completely independent 
> projects. [lang] is
> also neater - it only has static method classes plus String and Number
> ranges.
> 
> Of course a [lang] beta has now been released. with exceptions and
> serialization. Thus:
> 1) Move exceptions, enums and serialization to [pattern] and 
> break those
> dependent on the beta
> 2) Merge [pattern] into [lang], using c.a.c.lang.pattern-name packages
> 3) Leave as is, [pattern] dependent on [lang]
> 
> After much thought, I _really_ do prefer #2:
> - it makes [lang] more compelling
> - it follows what Java does (Serializable/Comparable are in java.lang)
> - it avoids this argument occurring each time we have 
> something new to add
> - [pattern] would remain in the sandbox as a staging ground 
> for trying out
> new patterns
> 
> I've tried to think of some possible downsides:
> - [pattern] is immature - well I would suggest only 
> Predicate, Transformer,
> Command and Factory for [lang] 1.0. These are long established from
> [collections] and fairly uncontroversial patterns
> - [lang] becomes diluted - I actually think it strengthens [lang] with
> broader appeal. Only a single Utils class must be allowed for 
> each pattern
> though, this will control bloat.
> 
> So, can we move for #2 - merge appropriate parts of [pattern] 
> into [lang] ??

+1 from the peanut gallery. ;-)

It'll save me having to ask myself where to find things, too.

--
Martin Cooper


> 
> Stephen
> 
> ----- Original Message -----
> From: "Henri Yandell" <bayard@generationjava.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Friday, August 09, 2002 4:37 PM
> Subject: RE: [pattern][lang] Cross dependecy
> 
> 
> >
> > I'm +1-maybe on this long term, but -1 on this now.
> >
> > I don't see any likelyhood that the upcoming release of 
> Lang will depend
> > on Patterns [I've been a bit delayed in organising things 
> due to my wife
> > being in hospital this week].
> >
> > As Lang is mostly full of static components, I've yet to 
> see any examples
> > of patterns that Lang would depend upon. I fully expect 
> there to be some
> > in the future, but currently?
> >
> > As for Commons-Core, I'm in favour of this too, 
> util/io/lang/patterns as
> > one jar, but have a feeling there are views against this.
> >
> > What I'd like to see:
> >
> > Lang 1.0 released soon. Enum and Reflection bits to be 
> considered, and
> > some hashing thing that Stephen was talking about before he 
> holidayed.
> >
> > Patterns maturing. I think there's a danger of seeing 
> everything as a
> > pattern and I expect Patterns to involve lots of debate and 
> changing of
> > minds. Suggestions as to what components would implement 
> which patterns
> > would be a good first start for every Commons component.
> >
> > NestableException staying where it is for the time-being.
> >
> > I'm seeing Patterns as being dependent on Lang [if it has 
> any such need]
> > but Lang would not depend on Patterns with the current code base.
> >
> > Once we have Util sorted, IO released, Patterns finalised, 
> Lang chunky,
> > then we would discuss the best next step.
> >
> > Just a suggestion :)
> >
> > Hen
> >
> > On Fri, 9 Aug 2002, Ola Berg wrote:
> >
> > > I have a third solution:
> > >
> > > Pattern shouldn\'t be dependent on anything, while I can 
> see useful
> > > dependencies from lang to pattern.
> > >
> > > 3) Remove NestableException (or whatever its name) from 
> lang and put
> > > it into patterns. * It is helpful mainly for generic interfaces of
> > > which pattern is full * things dependent on lang would be 
> dependent on
> > > pattens anyway, which is a good and natural thing. No need to mess
> > > things up with two parallel versions of lang.
> > >
> > > And BTW: I still propose a CommonsCore project (and
> > > commons-core-1.2.3.jar) consisting of (among others) the packages
> > > pattern and lang, in the same release cycle and developed 
> as a unit.
> > >
> > > /O
> > >
> > > --------------------
> > > ola.berg@arkitema.se
> > > 0733 - 99 99 17
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>



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


Mime
View raw message