I thought part of the aim of the Utils was to avoid having top level
classes, even if they are package scoped.
The problem as I see it is that someone new to the package will come along
and see maybe 60+ classes in the collections package. However, over half
could be package scoped with no way
On Sat, 15 Jun 2002, Stephen Colebourne wrote:
I thought part of the aim of the Utils was to avoid having top level
classes, even if they are package scoped.
yeah, in a way. They coule also be looked at as convenience methods
where you only need to import one class name to get all of the
]
Sent: Saturday, June 15, 2002 5:15 PM
Subject: Re: [Collections] Naming conventions
On Sat, 15 Jun 2002, Stephen Colebourne wrote:
I thought part of the aim of the Utils was to avoid having top level
classes, even if they are package scoped.
yeah, in a way. They coule also be looked
:18 PM
To: Jakarta Commons Developers List
Subject: Re: [Collections] Naming conventions [was
ComparableComparator
- nulls OK]
Good argument, and logical. However the 'Collections' class
could have 6 or
more groups of decorators if the dreams become reality. Maybe
this isn't
Colebourne
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 2:18 PM
To: Jakarta Commons Developers List
Subject: Re: [Collections] Naming conventions [was
ComparableComparator
- nulls OK]
Good argument, and logical. However the 'Collections'
class
could have 6
2) Subclassing would be more complex. Currently each
Predicate decorator
implementation extends another based on the interface
hierarchy. In order to
continue this, the static nested classes would need to be
package scoped,
not private. Not a big issue, but it should be noted.
I'm even
I personally like the Lists, Sets, Collections, etc naming,
too. We could put pass-through methods to
java.util.Collections on the commons.Collections class.
That way we can have our cake and eat it too.
I definitely agree that code like this is nicer:
Bag bag =
On Thu, 13 Jun 2002, Stephen Colebourne wrote:
What you describe does indeed compile, but isn't the proposal. The following
demonstrates (I hope) why they need to be package scoped.
public class CollectionUtils {
public static Collection predicatedCollection(Collection coll) {
return
On Thu, 13 Jun 2002, Jonathan Carlson wrote:
I personally like the Lists, Sets, Collections, etc naming,
too. We could put pass-through methods to
java.util.Collections on the commons.Collections class.
That way we can have our cake and eat it too.
too implies that Stephen was infavor of
On Thu, 13 Jun 2002, Jack, Paul wrote:
I'm even okay with the wrapper classes being package-protected
OUTER classes defined in the same source file. Having
package-protected classes still gives us a lot of leeway with
organizing things, as technically users shouldn't be using
-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 11, 2002 4:20 PM
To: Jakarta Commons Developers List
Subject: [Collections] Naming conventions [was ComparableComparator -
nulls OK]
Hi all,
Seeing as the collections package seems to be growing very
quickly, and some
PM
Subject: RE: [Collections] Naming conventions [was ComparableComparator -
nulls OK]
I think this is definitely a step in the right direction,
but that the ultimate strategy you've outlined is still
a little confusing.
Basically, we currently have two categories of decorator
classes:
1
Hi all,
Seeing as the collections package seems to be growing very quickly, and some
of the original classes were perhaps not named or grouped perfectly, I was
thinking that we might take this opportunity to agree some naming
conventions. I know, yawn, yawn, but anyway...
Here are the existing
On Wed, 12 Jun 2002, Stephen Colebourne wrote:
If we do this right, some of the current top level classes (eg.iterators)
could be deprecated and become merged into a factory style class, to the
benefit of the interface size.
Well thats my input (sorry for the long email!). We could really
14 matches
Mail list logo
