commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: commons.lang addition
Date Mon, 24 Jun 2002 23:27:51 GMT
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>


Mime
View raw message