You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/06/22 18:45:29 UTC
[Lang] Add Factory and Identifier to Lang
I would like to add the following to Lang
public interface Factory {
public Object create();
}
plus associated FactoryUtils class
public interface Identifiable {
public String getIdentifier() {
}
plus associated IdentifiableUtils class (depends on Factory, as creating an
identifier should be pluggable)
Any opinions?
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Lang][Util] Merge lang and util ? [was Re: [Lang] Add Factory and Identifier to Lang]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Now I'm starting to get really depressed. This approach seems to really
discourage any kind of sharing of code. What was commons for in the first
place?
Firstly, I apologise for not being around for the great Util break apart
debate. Maybe it was bad before. But its worse now.
If Lang was promoted to 1.0 today it would be with its current charter. What
if 2 months later IO was ready to become 1.0. Would it be merged into Lang?
Of course not. People would point at the Lang charter and reject it. And the
same process would happen for each tiny component.
What this way leads to is a miriad of tiny fiefdoms, either with lots and
lots of complex cross dependencies, or far more likely, duplication of code.
Unless commons as a whole takes ownership of this, each component will do
their own thing. Code which could build on Predicates, or Transforms, or
Factorys won't. Instead each component will come up with their own subtly
different solution. This is already shown with
Predicate/Transform/Closure/Comparator code being in collections. It is also
shown with the low level reflection code being in BeanUtils. It is already
shown with the Identifier code being in Betwixt. For commons to work, each
time a bit of code is committed there needs to be thought to say - is this
the right place for it, or can it be even more generic.
Clearly there is some bad past experience with developing Util in the
sandbox. But that shouldn't prevent the concept of a single commons proper
Lang/Util component being ruled out. Its fine to develop in the sandbox
separately, but we need to be sure that they will come together in commons
proper. Maybe thats the answer - Lang cannot be promoted alone, and when it
is a new name must be used. But that requires strong management and
control...
BTW: Where do you suggest that Predicate/Transform or Factory or
Identifiable or Comparator code should go? Are you proposing 4 new sandbox
components?
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
> -1
>
> The reason Util is eternally in the sandbox is because all manner of
> oddities get dumped into it. It's really Misc. That makes it very hard to
> manage and take to 1.0. In fact the common way to go from Util to a 1.0
> has so far been to break out of Util.
>
> Lang is not eternally in the sandbox as it's only been around since the
> start of the year. Projects are already linking to the sandboxed version
> of Lang and I think that once it goes into 1.0 there will be a high amount
> of usage.
>
> Taking Lang/IO/others out of Util was done so that they could manageably
> go to 1.0's. Util was a big mess when everything was unified.
>
> I do think that a distribution of Apache-Jakarta-Commons-Core should be
> deployable at some point, containing the net/io/collections/lang/other
> projects, but not that we should declare a new core project which would
> merely be a renaming of the old messy util.
>
> The current development methodology seems to be one of making it hard for
> a component-set to get into another project. Is this bad? For example.
> Lang goes to 1.0. Reflect and ThreadContext live in sandbox. When reflect
> goes to 1.0, it is migrated into Lang [after a heated discussion and many
> arguments]. Sandbox keeps a 'not in my backyard' attitude, then migrations
> to Commons are where those decisions are re-evaluated.
>
> Hen
>
> On Sat, 22 Jun 2002, Stephen Colebourne wrote:
>
> > Another thread has indicated that Lang and Util seem to be eternally in
the
> > sandbox, and never make it to commons proper. I suggest the reason is at
> > least in part that they are too small to stand alone.
> >
> > Avalon and collections threads have indicated that there are lots of
ideas
> > for *very* low level code. But noone quite wants to commit to whether
they
> > are lang, util or have to live in their own small component.
> >
(Predicate/Transform/Closure/Factory/Identifiable/Nameable/Comparators/Refle
> > ct/Thread/ etc.)
> >
> > I suggest the answer is to merge Lang and Util into one. A component
with
> > sufficient momentum, with sufficient developers, with sufficient useful
> > classes that it becomes *essential* to other commons projects to use it.
A
> > component that can actually make it to commons proper. If a new name is
> > needed fine - but this distinction between lang and util seems very
> > artificial (its blurred in Java too).
> >
> > I believe that most if not all commons projects _should_ be using a
common
> > core, but I am unconvinced that if Lang and Util were promoted today
that
> > _any_ commons project would actually choose to link to them. For me,
this is
> > not because of lack of tests or lack of useful code, but because of lack
of
> > 'essentialness'.
> >
> > My proposal would read along the lines of:
> > "xxx is a component to provide essential utility code useful to all
> > projects. Specific utilities are provided for the classes in java.lang
and
> > java.util, with the exception of collections. Also present is
functionality
> > that ideally should be present in the JDK."
> >
> > One thread used the term 'Organic' for the growth of commons. Is it time
for
> > a little pruning? Opinions?
> >
> > Stephen,
> > getting worried that all he's doing is proposing refactoring, but
feeling
> > compelled to do so ;-)
> >
> > ----- Original Message -----
> > From: "Henri Yandell" <ba...@generationjava.com>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Saturday, June 22, 2002 5:51 PM
> > Subject: Re: [Lang] Add Factory and Identifier to Lang
> >
> >
> > >
> > > -1. These aren't Lang things. They seem to me to be more a question of
> > > making a common set of interfaces for patterns.
> > >
> > > A package I have for myself is com.xx.patterns. Then inside that I
have a
> > > Null interface for showing if something implements the Null pattern,
and a
> > > set of Registrys for things that implement the Registry pattern [okay,
not
> > > really the right name for a pattern, is a name my colleagues and I
used
> > > for Factories with modifiable state].
> > >
> > > Lang is for things that map to java.lang or very core types, but not
for
> > > things that just seem very very generic.
> > >
> > > Just my -1,
> > >
> > > Hen
> > >
> > > On Sat, 22 Jun 2002, Stephen Colebourne wrote:
> > >
> > > > I would like to add the following to Lang
> > > >
> > > > public interface Factory {
> > > > public Object create();
> > > > }
> > > >
> > > > plus associated FactoryUtils class
> > > >
> > > >
> > > > public interface Identifiable {
> > > > public String getIdentifier() {
> > > > }
> > > >
> > > > plus associated IdentifiableUtils class (depends on Factory, as
creating
> > an
> > > > identifier should be pluggable)
> > > >
> > > > Any opinions?
> > > >
> > > > Stephen
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Lang][Util] Merge lang and util ? [was Re: [Lang] Add Factory
and Identifier to Lang]
Posted by Henri Yandell <ba...@generationjava.com>.
-1
The reason Util is eternally in the sandbox is because all manner of
oddities get dumped into it. It's really Misc. That makes it very hard to
manage and take to 1.0. In fact the common way to go from Util to a 1.0
has so far been to break out of Util.
Lang is not eternally in the sandbox as it's only been around since the
start of the year. Projects are already linking to the sandboxed version
of Lang and I think that once it goes into 1.0 there will be a high amount
of usage.
Taking Lang/IO/others out of Util was done so that they could manageably
go to 1.0's. Util was a big mess when everything was unified.
I do think that a distribution of Apache-Jakarta-Commons-Core should be
deployable at some point, containing the net/io/collections/lang/other
projects, but not that we should declare a new core project which would
merely be a renaming of the old messy util.
The current development methodology seems to be one of making it hard for
a component-set to get into another project. Is this bad? For example.
Lang goes to 1.0. Reflect and ThreadContext live in sandbox. When reflect
goes to 1.0, it is migrated into Lang [after a heated discussion and many
arguments]. Sandbox keeps a 'not in my backyard' attitude, then migrations
to Commons are where those decisions are re-evaluated.
Hen
On Sat, 22 Jun 2002, Stephen Colebourne wrote:
> Another thread has indicated that Lang and Util seem to be eternally in the
> sandbox, and never make it to commons proper. I suggest the reason is at
> least in part that they are too small to stand alone.
>
> Avalon and collections threads have indicated that there are lots of ideas
> for *very* low level code. But noone quite wants to commit to whether they
> are lang, util or have to live in their own small component.
> (Predicate/Transform/Closure/Factory/Identifiable/Nameable/Comparators/Refle
> ct/Thread/ etc.)
>
> I suggest the answer is to merge Lang and Util into one. A component with
> sufficient momentum, with sufficient developers, with sufficient useful
> classes that it becomes *essential* to other commons projects to use it. A
> component that can actually make it to commons proper. If a new name is
> needed fine - but this distinction between lang and util seems very
> artificial (its blurred in Java too).
>
> I believe that most if not all commons projects _should_ be using a common
> core, but I am unconvinced that if Lang and Util were promoted today that
> _any_ commons project would actually choose to link to them. For me, this is
> not because of lack of tests or lack of useful code, but because of lack of
> 'essentialness'.
>
> My proposal would read along the lines of:
> "xxx is a component to provide essential utility code useful to all
> projects. Specific utilities are provided for the classes in java.lang and
> java.util, with the exception of collections. Also present is functionality
> that ideally should be present in the JDK."
>
> One thread used the term 'Organic' for the growth of commons. Is it time for
> a little pruning? Opinions?
>
> Stephen,
> getting worried that all he's doing is proposing refactoring, but feeling
> compelled to do so ;-)
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, June 22, 2002 5:51 PM
> Subject: Re: [Lang] Add Factory and Identifier to Lang
>
>
> >
> > -1. These aren't Lang things. They seem to me to be more a question of
> > making a common set of interfaces for patterns.
> >
> > A package I have for myself is com.xx.patterns. Then inside that I have a
> > Null interface for showing if something implements the Null pattern, and a
> > set of Registrys for things that implement the Registry pattern [okay, not
> > really the right name for a pattern, is a name my colleagues and I used
> > for Factories with modifiable state].
> >
> > Lang is for things that map to java.lang or very core types, but not for
> > things that just seem very very generic.
> >
> > Just my -1,
> >
> > Hen
> >
> > On Sat, 22 Jun 2002, Stephen Colebourne wrote:
> >
> > > I would like to add the following to Lang
> > >
> > > public interface Factory {
> > > public Object create();
> > > }
> > >
> > > plus associated FactoryUtils class
> > >
> > >
> > > public interface Identifiable {
> > > public String getIdentifier() {
> > > }
> > >
> > > plus associated IdentifiableUtils class (depends on Factory, as creating
> an
> > > identifier should be pluggable)
> > >
> > > Any opinions?
> > >
> > > Stephen
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Lang][Util] Merge lang and util ? [was Re: [Lang] Add Factory and Identifier to Lang]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Another thread has indicated that Lang and Util seem to be eternally in the
sandbox, and never make it to commons proper. I suggest the reason is at
least in part that they are too small to stand alone.
Avalon and collections threads have indicated that there are lots of ideas
for *very* low level code. But noone quite wants to commit to whether they
are lang, util or have to live in their own small component.
(Predicate/Transform/Closure/Factory/Identifiable/Nameable/Comparators/Refle
ct/Thread/ etc.)
I suggest the answer is to merge Lang and Util into one. A component with
sufficient momentum, with sufficient developers, with sufficient useful
classes that it becomes *essential* to other commons projects to use it. A
component that can actually make it to commons proper. If a new name is
needed fine - but this distinction between lang and util seems very
artificial (its blurred in Java too).
I believe that most if not all commons projects _should_ be using a common
core, but I am unconvinced that if Lang and Util were promoted today that
_any_ commons project would actually choose to link to them. For me, this is
not because of lack of tests or lack of useful code, but because of lack of
'essentialness'.
My proposal would read along the lines of:
"xxx is a component to provide essential utility code useful to all
projects. Specific utilities are provided for the classes in java.lang and
java.util, with the exception of collections. Also present is functionality
that ideally should be present in the JDK."
One thread used the term 'Organic' for the growth of commons. Is it time for
a little pruning? Opinions?
Stephen,
getting worried that all he's doing is proposing refactoring, but feeling
compelled to do so ;-)
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, June 22, 2002 5:51 PM
Subject: Re: [Lang] Add Factory and Identifier to Lang
>
> -1. These aren't Lang things. They seem to me to be more a question of
> making a common set of interfaces for patterns.
>
> A package I have for myself is com.xx.patterns. Then inside that I have a
> Null interface for showing if something implements the Null pattern, and a
> set of Registrys for things that implement the Registry pattern [okay, not
> really the right name for a pattern, is a name my colleagues and I used
> for Factories with modifiable state].
>
> Lang is for things that map to java.lang or very core types, but not for
> things that just seem very very generic.
>
> Just my -1,
>
> Hen
>
> On Sat, 22 Jun 2002, Stephen Colebourne wrote:
>
> > I would like to add the following to Lang
> >
> > public interface Factory {
> > public Object create();
> > }
> >
> > plus associated FactoryUtils class
> >
> >
> > public interface Identifiable {
> > public String getIdentifier() {
> > }
> >
> > plus associated IdentifiableUtils class (depends on Factory, as creating
an
> > identifier should be pluggable)
> >
> > Any opinions?
> >
> > Stephen
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Lang] Add Factory and Identifier to Lang
Posted by Henri Yandell <ba...@generationjava.com>.
-1. These aren't Lang things. They seem to me to be more a question of
making a common set of interfaces for patterns.
A package I have for myself is com.xx.patterns. Then inside that I have a
Null interface for showing if something implements the Null pattern, and a
set of Registrys for things that implement the Registry pattern [okay, not
really the right name for a pattern, is a name my colleagues and I used
for Factories with modifiable state].
Lang is for things that map to java.lang or very core types, but not for
things that just seem very very generic.
Just my -1,
Hen
On Sat, 22 Jun 2002, Stephen Colebourne wrote:
> I would like to add the following to Lang
>
> public interface Factory {
> public Object create();
> }
>
> plus associated FactoryUtils class
>
>
> public interface Identifiable {
> public String getIdentifier() {
> }
>
> plus associated IdentifiableUtils class (depends on Factory, as creating an
> identifier should be pluggable)
>
> Any opinions?
>
> Stephen
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>