Re: [lang] Designs and Futures

[Stephen Colebourne <sc...@btopenworld.com>]

There are two areas that I see commons as poor at achieving - release early
release often and dependencies. The code itself is generally very good
(despite what some might say).

[lang] is an example of this. It has needed a release for some time, if only
to fix some of the glaring bugs in 2.0. It has also had changes applied to
it that increase dependencies.

I know that many reading this don't get my point here. Perhaps if I used the
word coupling instead that would help? In the Validate case, there is no
need for Validate to be coupled to StringUtils and ArrayUtils. It wasn't in
its original design, I was just reverting code back to 2.0.

This extends to other packages - ideally, no subpackage within lang should
depend on another. We won't achieve that, but it should be a basic goal. (It
should be noted that in [collections] I introduced more
dependencies/coupling between classes in v3.0 and it has since been shown to
be a Bad Thing)

As I've tried to explain elsewhere, [lang] is not one jar file but many. It
is a place where these tiny pieces of code can be grouped together and
looked after, because even smaller projects tend not to work. After all, we
ought to be able to create an exception jar, or an enums jar, or a validate
jar if we wanted.

Finally, it should be noted that [lang] has about 30 open calls, and many
are valid. This suggests a wide user base who want this component supported
and improved. The issue for us is more to do with [lang] satisfying our own
personal isues already, so we don't feel motivated to do anything about it -
its not our itch any more. But somehow, we need to at least get 2.1 out,
then take it from there.

[lang] is actually a great achievement, as almost certainly the most widely
used library of its type. Lets not loose that achievement.

Stephen

----- Original Message -----
From: "matthew.hawthorne" <ma...@apache.org>
> Gary Gregory wrote:
> > Sorry for the flame but this is a 'shake-my-head-in-disbelief' moment
> > that I find discouraging.
>
> I pretty much agree, but from my POV [lang] stopped moving forward a
> while ago anyway.  Most new requests
> or ideas are rejected as "out of scope" (which is usually valid), and
> the project has shifted into
> maintenance mode.  Along with this came a certain identity crisis, and
> that's why the cut-and-paste
> philosophy came along.
>
> As another example, I've never even liked the public constructor in
> *Utils classes, even though I understand why it's
> done.  Helping and supporting users is important, but I think there is a
> certain line that has to be drawn.
> I think that developers should have the freedom to make classes and
> methods final where appropriate,
> and make other design decisions that may limit the possible uses of the
> library.  In losing that ability, I believe that
> the quality of the code suffers.  And for someone like me, it makes me
> less motivated to become involved or share ideas.
>
> I may be dead wrong, these are just some feelings that I have.
>
> ---------------------------------------------------------------------
> 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

Re: [lang] Designs and Futures

[Henri Yandell <ba...@generationjava.com>]

On Wed, 2 Jun 2004, Fredrik Westermarck wrote:

> While we're talking about Validate anyway - how about renaming it to
> ValidateUtils like all other utility classes?

It doesn't act on a Validate object. XxxUtils is a set of static
procedural style functions which act on an Xxx [at least in my
straitjacketed world].

Hen


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

Re: [lang] Designs and Futures

[Fredrik Westermarck <fr...@mdh.se>]

Henri Yandell wrote:

> As a basic rule, I think it's pretty fair to state that package hierarchy
> should be obeyed as far as dependencies goes. This means that a package's
> classes may not depend on a sibling package, or a child package, but it may
> depend on a super-package or classes within the same package.

Never thought about package dependencies that way, but it seems 
reasonable too me - atleast when dealing with utility classes like the 
ones in [lang].

> Looking at the Validate example, I think it's pretty small fry. It's in
> the same package as String/ArrayUtils, so logically should be able to
> depend on them, and it's merely the isEmpty methods.
> 
> I'm +1 to maintaining the isEmpty calls, but do agree with Stephen's
> general principle.

This is really a non-issue but I'll take the opportunity to present my 
opinion anyway. ;-)

Not reusing your own utilities because you want to be able to do 
cut-and-paste coding does seem a bit far fetched too me. It's my opinion 
that [lang] should be considered as a whole and complete product. The 
main goal is not to distribute a bunch of source files that people can 
cut-and-paste from, but a whole and functional product. If someone out 
there downloads the source code and on its own cut-and-pastes a method 
they have to adopt it to their environment and their use case as well as 
maintaining it. We cannot (and should not in my opinion) predict what 
metohods people want to be able to cut-and-paste.

If we decide that we do want to support cut-and-paste coding it ought to 
be stated as a design goal in the docs - it's a bit hard to guess this 
as a newcomer or an outsider. :-)

While we're talking about Validate anyway - how about renaming it to 
ValidateUtils like all other utility classes?

Regards,
Fredrik Westermarck


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

Re: [lang] Designs and Futures

[Phil Steitz <ph...@steitz.com>]

Henri Yandell wrote:
> 
> On Wed, 2 Jun 2004, Stephen Colebourne wrote:
> 
> 
>>There are two areas that I see commons as poor at achieving - release early
>>release often and dependencies. The code itself is generally very good
>>(despite what some might say).
> 
> 
> Agreed on both.

Yes.  And I am learning that there is a relation between the two :-(
> 
> 
> As a basic rule, I think it's pretty fair to state that package hierarchy
> should be obeyed as far as dependencies goes. This means that a package's
> classes may not depend on a sibling package, or a child package, but it may
> depend on a super-package or classes within the same package.
> 
> Looking at the Validate example, I think it's pretty small fry. It's in
> the same package as String/ArrayUtils, so logically should be able to
> depend on them, and it's merely the isEmpty methods.
> 
> I'm +1 to maintaining the isEmpty calls, but do agree with Stephen's
> general principle.

I agree; both the principle and (with Stephen) in this (small) case.
> 
> 
>>Finally, it should be noted that [lang] has about 30 open calls, and many
>>are valid. This suggests a wide user base who want this component supported
>>and improved. The issue for us is more to do with [lang] satisfying our own
>>personal isues already, so we don't feel motivated to do anything about it -
>>its not our itch any more. But somehow, we need to at least get 2.1 out,
>>then take it from there.
> 
> 
> Agreed, and I've been slacking.

You're not the only one ;-)

Phil


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

Re: [lang] Designs and Futures

[Henri Yandell <ba...@generationjava.com>]

On Wed, 2 Jun 2004, Stephen Colebourne wrote:

> There are two areas that I see commons as poor at achieving - release early
> release often and dependencies. The code itself is generally very good
> (despite what some might say).

Agreed on both.

> [lang] is an example of this. It has needed a release for some time, if only
> to fix some of the glaring bugs in 2.0. It has also had changes applied to
> it that increase dependencies.

[io] is out, so unless anyone is against it, I'll start working on [lang]
bugs on my Saturday evening Apache sessions.

> I know that many reading this don't get my point here. Perhaps if I used the
> word coupling instead that would help? In the Validate case, there is no
> need for Validate to be coupled to StringUtils and ArrayUtils. It wasn't in
> its original design, I was just reverting code back to 2.0.
>
> This extends to other packages - ideally, no subpackage within lang should
> depend on another. We won't achieve that, but it should be a basic goal. (It

As a basic rule, I think it's pretty fair to state that package hierarchy
should be obeyed as far as dependencies goes. This means that a package's
classes may not depend on a sibling package, or a child package, but it may
depend on a super-package or classes within the same package.

Looking at the Validate example, I think it's pretty small fry. It's in
the same package as String/ArrayUtils, so logically should be able to
depend on them, and it's merely the isEmpty methods.

I'm +1 to maintaining the isEmpty calls, but do agree with Stephen's
general principle.

> Finally, it should be noted that [lang] has about 30 open calls, and many
> are valid. This suggests a wide user base who want this component supported
> and improved. The issue for us is more to do with [lang] satisfying our own
> personal isues already, so we don't feel motivated to do anything about it -
> its not our itch any more. But somehow, we need to at least get 2.1 out,
> then take it from there.

Agreed, and I've been slacking.

> [lang] is actually a great achievement, as almost certainly the most widely
> used library of its type. Lets not lose that achievement.

My sentiments too.

Hen


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