commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@eurobell.co.uk>
Subject Re: [Collections] Naming conventions
Date Thu, 13 Jun 2002 20:41:50 GMT
Following this through we have
Collections
Lists
Sets
Maps
Bags
Trees (hopefully!)
Predicates
Transforms
Factories
Comparators
Iterators

I see three issues:
1) 'Collections' still clashes with java.util. We could:
- say tough, use the full package name
- name it ApacheCollections
- name it CommonsCollections
- use the name CollectionUtils for just that one
- use the name XxxUtils for all the above

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.

3) Defining the relationship between ListUtils and Lists, CollectionUtils
and Collections and MapUtils and Maps. Unfortunately, ListUtils,
CollectionUtils and MapUtils are @since 1.0, so we are not free to rename
them.


After a little thought, I think I favour adding Utils to all of the above.
Results in no clashes with Java, and just involves adding methods to
ListUtils, CollectionUtils and MapUtils.

On method names, I agree with your implicit use of   yyyedXxx, eg.
filteredMap or predicatedSet

Stephen

BTW: I thought of two more decorator groups - Transform (already discussed a
little while back) and FixedSize (doesn't allow the size to change). And I
like the Comparator to Predicate idea.

----- Original Message -----
From: Jack, Paul <pjack@sfaf.org>
> Here's an idea.  We can make the source more manageable
> and effectively limit the number of public classes by
> breaking my One Decorator Class To Rule Them All into
> smaller ones based on subinterface:
>
>    Bags (for SortedBags too)
>      predicatedBag
>      predicatedSortedBag
>      synchronizedBag
>      synchronizedSortedBag
>      unmodifiableBag
>      unmodifiableSortedBag
>      eventBag
>      eventSortedBag
>      filterBag
>      filterSortedBag
>    Lists
>      predicatedList
>      eventList
>      filterList
>    Maps (for SortedMaps and MultiMaps too)
>    Sets
>
> It avoids the naming collision, keeps the source in
> distinct places, and prevents us from having another
> public class every time somebody comes up with
> another great decorator idea...
>
> Though I guess we would need another public class
> every time somebody comes up with another great
> Collection subinterface.  But that doesn't seem like
> it would happen as often as new decorators (we already
> have 5 new decorator ideas on the table, no
> outstanding Collection subinterfaces...)
>
> Also, the more I think about it, it seems that organizing
> the source code according to return type makes a lot of
> sense, as a rule of thumb.  For instance, where do we put
> this method?
>
>   // Returns a predicate that returns true for objects
>   // that are greater than o, according to the sort
>   // order specified by c.
>   public Predicate greaterThan(Object o, Comparator c);
>
> It uses a comparator, but produces a predicate.  Does it
> go in Comparators or Predicates?  With the
> organize-by-return-type approach, it's obvious that we
> put it in PredicateUtils; and it's hopefully obvious to
> a user of the library where to find such a beast.
>
> -Paul
>
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@eurobell.co.uk]
> > 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 or
> > more groups of decorators if the dreams become reality. Maybe
> > this isn't a
> > problem, but I wouldn't want that class to contain all the
> > static nested
> > classes (for maintainability)
> >
> > There is another factor - the classes don't just contain decorators.
> > FactoryUtils/PredicateUtils (current names) create
> > Factory/Predicate objects
> > not decorate them.
> >
> > Some possibilities:
> > - CollectionUtils
> > ie. add to existing class, probably should merge in ListUtils
> > too - this
> > seems quite a big change. And MapUtils doesn't fit well (its rather a
> > strange group of methods)
> >
> > - Decorators
> > - CollectionDecorators
> > - DecoratedCollections
> > - DecoratorUtils
> > these emphasise the role of the resultant classes, but how is
> > the source
> > laid out
> >
> > - SynchronizedCollections, PredicatedCollections, ... as I originally
> > proposed
> > these emphasise the particular decorator, and fit well with
> > managable source
> > units
> >
> >
> > Deciding where the source will go is another factor in this.
> > Nice can of
> > worms!
> >
> > Stephen
>
> --
> 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