commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fredrik Westermarck <fredrik.westerma...@mdh.se>
Subject Re: [lang] Designs and Futures
Date Wed, 02 Jun 2004 21:07:33 GMT
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


Mime
View raw message