You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Jack, Paul" <pj...@sfaf.org> on 2002/06/13 19:16:01 UTC
RE: [Collections] Naming conventions
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections] Naming conventions
Posted by "Michael A. Smith" <ma...@apache.org>.
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 Lists, Sets naming, but in
that same email:
> > After a little thought, I think I favour adding Utils to
> > all of the above.
;)
> The only people that would have to use the whole path name
> would be those who import java.util.*. And I, personally,
> think that is a sloppy convention anyways because it makes
> it very difficult on new Java developers trying to learn a
> system, in addition to Sun's suggestions against it.
>
> This next idea would be a last resort, but we could come up
> with an automatic java.util import generator for those
> java.util classes used in the class. It would be
> relatively easy to do with regular expressions and the
> BeanShell.
Too much work for users. I will -1 an
org.apache.commons.collections.Collections class.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections] Naming conventions
Posted by Jonathan Carlson <jo...@yahoo.com>.
Concerning the Collections name collisions. Here's another
option:
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.
The only people that would have to use the whole path name
would be those who import java.util.*. And I, personally,
think that is a sloppy convention anyways because it makes
it very difficult on new Java developers trying to learn a
system, in addition to Sun's suggestions against it.
This next idea would be a last resort, but we could come up
with an automatic java.util import generator for those
java.util classes used in the class. It would be
relatively easy to do with regular expressions and the
BeanShell.
Jonathan
--- Stephen Colebourne <sc...@eurobell.co.uk> wrote:
> 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 <pj...@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:
> <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>
>
=====
Jonathan Carlson
joncrlsn@users.sf.net
Minneapolis, Minnesota
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections] Naming conventions
Posted by "Michael A. Smith" <ma...@apache.org>.
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 new PredicatedCollection(coll);
> }
> static class PredicatedCollection {
> }
> }
> public class ListUtils {
> public static List predicatedList(List list) {
> return new PredicatedList(list);
> }
> static class PredicatedList extends PredicatedCollection {
> }
> }
got it... I thought I was missing something. :) didn't realize you were
referring to cross-xxxUtils inheritance. Yes, that would need to be
package private. I'm not sure that is such a big deal though.
> > I haven't fully digested this thread yet, but I'm inclined to agree with
> > you.
>
> It is quite a lot to digest, but given the number of ideas that are floating
> about, we do seem to need it. There could be some work for the committers to
> manage the patches etc. for any renaming however!
yup... believe me, I know... I'm still trying to manage the patches
Paul sent in for the new testing framework... :)
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections] Naming conventions
Posted by Stephen Colebourne <sc...@eurobell.co.uk>.
From: Michael A. Smith <ma...@apache.org>
> On Thu, 13 Jun 2002, Stephen Colebourne wrote:
> > 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.
>
> Maybe I'm misunderstanding what you mean here, but this compiles just
> fine:
>
> public class Foo {
> private static class Bar {
> }
> private static class Baz extends Bar {
> }
> }
>
> The Bar class is private outside its scope of Foo, but since Baz is in
> the scope of Foo, it can still see Bar.
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 new PredicatedCollection(coll);
}
static class PredicatedCollection {
}
}
public class ListUtils {
public static List predicatedList(List list) {
return new PredicatedList(list);
}
static class PredicatedList extends PredicatedCollection {
}
}
> > 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.
>
> I haven't fully digested this thread yet, but I'm inclined to agree with
> you.
It is quite a lot to digest, but given the number of ideas that are floating
about, we do seem to need it. There could be some work for the committers to
manage the patches etc. for any renaming however!
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections] Naming conventions
Posted by "Michael A. Smith" <ma...@apache.org>.
On Thu, 13 Jun 2002, Stephen Colebourne wrote:
> 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.
Maybe I'm misunderstanding what you mean here, but this compiles just
fine:
public class Foo {
private static class Bar {
}
private static class Baz extends Bar {
}
}
The Bar class is private outside its scope of Foo, but since Baz is in
the scope of Foo, it can still see Bar.
> 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.
I haven't fully digested this thread yet, but I'm inclined to agree with
you.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections] Naming conventions
Posted by Stephen Colebourne <sc...@eurobell.co.uk>.
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 <pj...@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:
<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>