commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: commons.lang addition
Date Mon, 24 Jun 2002 23:46:20 GMT
So why don't you start a core package in the sandbox and start adding
things to it?

I can see your side of the argument, but I tend to agree with Craig that
something like this can grow too large.  Can you start with a charter
that you think would keep it narrow enough to be maintainable?

Scott

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Monday, June 24, 2002 4:28 PM
> To: Jakarta Commons Developers List
> Subject: Re: commons.lang addition
> 
> 
> From: "Henri Yandell" <bayard@generationjava.com>
> > My -1 for Factory and Identifiable were on the grounds that 
> they don't 
> > fit the current proposal for Lang. I think there is a good 
> reason for 
> > a Core project, but I don't think common utility classes 
> fit into it. 
> > Basically
> > because:
> >
> > Lang is something which any Java developer should be able 
> to use, with 
> > the possible exception of J2ME people.
> >
> > Core would be something which developers would choose to 
> use. There's 
> > no reason why the factories I write should adhere to Factory.
> 
> So why do you use Comparator (I'm guessing you do!) ? Because 
> it is a very simple concept, easily understood, that allows 
> great reuse of code. Despite the fact that it requires casting.
> 
> A Factory is no different. If it was in the JDK the argument 
> wouldn't exist. Configuration tools could recognise Factories 
> and refer to them by interface. Libraries of factories could 
> be built up. (As has been pointed out, Factories are not 
> unlike type conversions - they just convert nothingness to something)
> 
> Its the same with any common code isn't it? The first time 
> you write it you don't see the benefits of treating it 
> generically. Only after you've done it 2, 3, 4 times do you 
> think about the refactoring that you then realise should have 
> happened at the start.
> 
> 
> > One of the problems on the core thread is the difference in view of 
> > what core is. Someone [I forget who] posted with a list of core 
> > objects which completely did not mention the Util's in Commons but 
> > focused on transformations instead. I think that sounds like a good 
> > idea, but isn't something I would jump to use. Factory and 
> > Identifiable sound like low level components there.
> 
> So Lang will contain classes to help with Strings, Numbers 
> and Number Ranges, but nothing to help convert between 
> Strings, Numbers and NumberRanges? Actually what I suspect 
> will happen is that those methods _will_ be added in Lang, 
> but just as extra methods on Strings and Numbers, thus 
> incompatable with and duplicating work elsewhere (this is why 
> I used the term 'madness')
> 
> > I think that's the big thing for me. Lang should remain a JDK only 
> > focused project.
> 
> If thats the case then the charter should be changed in section (1)
> 
> > I'm one voice though, outvote me :)
> I'd rather convince you ;-)
> 
> Stephen
> 
> 
> > On Mon, 24 Jun 2002, Stephen Colebourne wrote:
> >
> > > From: "Henri Yandell" <bayard@generationjava.com>
> > >
> > > Apologies for not quoting the charter accurately, but I was 
> > > intending to
> use
> > > the words that have been used against Factory and Identifiable.
> > >
> > > To me, it seems inconsistent to take in reflect, system 
> and thread 
> > > (both currently located elsewhere) but deny new very primitive 
> > > concepts (which
> is
> > > explicity allowed for in the Scope paragraph). By 
> proposing to take 
> > > in
> these
> > > three you are, in my eyes, creating the Core component that I'm 
> > > arguing
> for.
> > > Just under a different banner. (theres a bit of deja vue about 
> > > this...)
> > >
> > > So, I don't care if its called Lang rather than Core - so 
> long as it 
> > > has
> the
> > > right stuff in it!
> > >
> > > Stephen
> > >
> > > > ******************************************************
> > > >
> > > > <h3>(0) Rationale</h3>
> > > >
> > > > <p>The standard Java libraries fail to provide enough 
> methods for 
> > > > manipulation of its main components. The <em>Lang</em> Package
> provides
> > > > these extra methods. There are other classes which might 
> > > > justifiably be included in java.lang someday, this package also 
> > > > provides for
> them.</p>
> > > >
> > > > <h3>(1) Scope of the Package</h3>
> > > >
> > > > <p>This proposal is to create a package of Java utility classes

> > > > for
> the
> > > > classes that are in java.lang's hierarchy, or are 
> considered to be 
> > > > so standard as to justify existence in java.lang.</p>
> > > >
> > > > <h3>(1.5) Interaction With Other Packages</h3>
> > > >
> > > > <p><em>Lang</em> relies only on standard JDK 1.2 (or

> later) APIs 
> > > > for production deployment.  It utilizes the JUnit unit testing 
> > > > framework
> for
> > > > developing and executing unit tests, but this is of 
> interest only 
> > > > to developers of the component.  Lang will be a dependency for 
> > > > several existing components in the open source world.</p>
> > > >
> > > > **************************************************************
> > > >
> > > > Now, I'm not saying I'm + or - the System code, but 
> your charter 
> > > > for
> Lang
> > > > is wrong.
> > > >
> > > > In name the code sounds as though it enhances the 
> java.lang.System
> class,
> > > > in a similar way to the Reflect's enhancement of 
> > > > java.lang.reflect.*
> and
> > > > ThreadContext's java.lang.Thread enhancement. I've not 
> looked at 
> > > > the
> code
> > > > for system or reflect yet, but I believe that the ThreadContext 
> > > > does enhance java.lang.Thread.
> > > >
> > > > The important issue with the System code is, does it enhance 
> > > > java.lang.System. If so, then it fulfills the charter of Lang. 
> > > > Then I would imagine the question becomes more one of, does it 
> > > > 'fit' in Lang
> and
> > > > does the submitter wish it to live in Lang or believe 
> it would be 
> > > > healthier outside.
> > > >
> > > > Hen
> > > >
> > > > On Mon, 24 Jun 2002, Stephen Colebourne wrote:
> > > >
> > > > > Berin,
> > > > > +1 for it being in commons.
> > > > > -1 for it being in Lang - but only because to do so breaks the
> charter
> > > of
> > > > > Lang. (Which is to provide methods to assist with the 
> > > > > neo-primitive
> > > types in
> > > > > Java - Objects, Strings and Numbers)
> > > > >
> > > > > Now I'm not saying that I agree with that definition, but the
> current
> > > state
> > > > > of affairs is that every distinct bit of 
> functionality goes in 
> > > > > its
> own
> > > > > sandbox project.  Thus a System project would seem 
> appropriate. 
> > > > > (See
> > > also
> > > > > core architecture thread). Of course that will probably mean 
> > > > > your
> code
> > > will
> > > > > never be released :-(  but what the heck - nobody here seems
> bothered by
> > > > > that at the moment.
> > > > >
> > > > > Stephen
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Scott Sanders" <ssanders@nextance.com>
> > > > > To: "Jakarta Commons Developers List"
> <commons-dev@jakarta.apache.org>
> > > > > Sent: Monday, June 24, 2002 6:50 PM
> > > > > Subject: RE: commons.lang addition
> > > > >
> > > > >
> > > > > Yes, I have always wanted to know these things, but 
> was always 
> > > > > too
> lazy
> > > > > to code it.  +1
> > > > >
> > > > > Scott
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > > > > Sent: Monday, June 24, 2002 10:33 AM
> > > > > > To: 'Jakarta Commons Developers List'
> > > > > > Subject: RE: commons.lang addition
> > > > > >
> > > > > >
> > > > > > > From: Scott Sanders [mailto:ssanders@nextance.com]
> > > > > > >
> > > > > > > Unless we created an os package, I would say lang is the
> > > > > > closest fit.
> > > > > >
> > > > > > Yes, but is this something that Commons would want? 
>  I use it 
> > > > > > in my Excalibur Command and Event packages to determine the

> > > > > > size of the thread pool (for processing asynchronous 
> > > > > > commands).  I'm sure that others may have wanted a solution

> > > > > > for this--but I wanted to make sure before I migrated it.
> > > > > >
> > > > > > > > I use it to determine how many threads I should 
> have in a 
> > > > > > > > ThreadPool.  I make it a multiple of the number of

> > > > > > > > processors. Granted, for some operating 
> systems, they only 
> > > > > > > > support
> > > > > > one processor
> > > > > > > > (like Win 9x/ME).  If there is no adapter for a system,

> > > > > > > > then
> it
> > > > > > > > assumes there is only one processor.
> > > > > > > >
> > > > > > > > Does this sound like something we want to support
in 
> > > > > > > > Commons
> Lang?
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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>
> > > >
> > >
> > >
> > > --
> > > 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