commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <...@apache.org>
Subject Re: [reflect][collection] Predicate - a question
Date Mon, 17 Jun 2002 20:12:27 GMT
On Mon, 17 Jun 2002, Juozas Baliuka wrote:
> It is nothing bad to have both, public classes for extentions and static
> methods used to "hide", cache or pool something, it is more problems to use
> this kind of API, but it is possible
> to solve it by moving public classes to something like "impl" subpackages.

I agree, it is not bad to have both static factory methods and public 
classes.   In fact, I have already mentioned something like that on this 
list:

On Thu, 13 Jun 2002, Michael A. Smith wrote:
> we could even make them public classes and allow users to extend them on
> their own (using the XXXUtils.whatever methods as convenience methods)

and

On Fri, 14 Jun 2002, Michael A. Smith wrote:
> seems reasonable...  but I think we should take small steps in terms of
> the public API.  Make the decorators available via the Utils, then if
> users really want them, move the classes out from package private status
> to public in a separate package...

My questions to Ola were not about the benefits of having the classes 
available as public static classes (either as inner classes or top-level 
classes).  Instead, I was asking why the "static factory methods 
eventually will become a burden" which we will later "regret" and why it 
is "sad" that we have chosen to support static factory methods.  

regards,
michael


> 
> ----- Original Message -----
> From: "Michael A. Smith" <mas@apache.org>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>; "Ola
> Berg" <ola.berg@arkitema.se>
> Sent: Monday, June 17, 2002 9:43 PM
> Subject: RE: [reflect][collection] Predicate - a question
> 
> 
> > On Mon, 17 Jun 2002, Ola Berg wrote:
> > > Personally I think that util classes with static factory methods
> > > eventually will become a burden, and that you later on will regret the
> > > approach.
> >
> > Why?  I'm interested in hearing your argument.
> >
> > > My favourite practice to reduce complexity of the public API when the
> > > number of decorators and implementations tend to grow is the static
> > > inner class that implements the outer interface:
> > >
> > > public interface Predicate {
> > >     public void evaluate(...);
> > >
> > >     public static class Or implements Predicate {
> > >         ...
> > >     };
> > > }
> >
> > It's not possible to do that for the Map, Set, List, Collection
> > interfaces, which is the primary motication for the collections package.
> >
> > > Personally, I think it is sad that you consider the static factory
> > > method in util class approach for your Iterators, but it ain\'t my API
> > > or my decision, and I definitely don\'t want to start flaming.
> >
> > Why?  Please explain.  It's not a flame if we talk technical merits and
> > avoid personal attacks.
> >
> > michael
> >
> >
> > --
> > 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>
> 



--
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