You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/08/07 01:46:25 UTC
Re: [IO] filefilter sub-package
Ola,
If you do have a chance to think about using [pattern] Predicates as
FileFilters that would be good. PredicateUtils already provides far more
And/Or/Xor/Not/... behaviour than FileFilter stuff does. However, on my last
quick think about this, it seemed to need lots of adaptors and I couldn't
quite get to a nice solution.
We should definitely have a FileFilterUtils though to hide the classes.
Stephen
----- Original Message -----
From: "Ola Berg" <ol...@arkitema.se>
To: <co...@jakarta.apache.org>
Sent: Monday, July 29, 2002 9:59 AM
Subject: RE: [IO] filefilter sub-package
> Hen says:
>
> >Probably this is unnecessary, but it feels poor to choose one
> >implementation other the other. Maybe there could be two abstract
classes,
> >one for each type of sub-class, with a common interface between them.
>
> 1) Should this be public? I think so, because the need of static adaption
is there for others too.
>
> 2) If the adapter superclass(es) are to be public, they should be safe and
have clear responsibilities. So, yes, Two classes will do fine.
>
> >There\'s probably a more elegant solution?
>
> I propose that we hide all implementing classes for the decorators in io,
both streams and filters, and use decorating methods a la
FileFilterUtils.invertFileFilter( myFileFilter).
>
> The dynamic adaption from FilenameFilter to FileFilter and vv could go
there too.
>
> The public interface of io is to big now IMO. And it is anyway a good idea
to hide constructors and implementing classes as much as you can.
>
> A third thing to do would be to check compatibility/integration with lang
and patterns as I think io, lang and patterns operates on a very low level,
and that I can see that there will be a future desire to merge at least
these three packages into a Commons-Core component. What about the
relationship between Predicate and the filters for instance?
>
> A fourth thing to do would be to check compability/interation with net, as
the conceptual distinction between io and net in general (and java.net and
java.io in particular) is somewhat fuzzy. They _ought_ to be related in one
way or another, given the relationship between their problem domains.
>
> I can look into the decorator stuff when it comes to FileFilters. But
where are your classes, are they really committed? I just did an update,
maybe I forgot some option to the cvs command?
>
> /O
>
> --------------------
> ola.berg@arkitema.se
> 0733 - 99 99 17
>
> --
> 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>