Is there a 'Filter' or 'Predicate' interface anywhere in the JDK?

T

Tom Anderson

Hi chaps,

I just wrote this interface:

public interface Filter<T> {
boolean accept(T obj);
}

That seems awfully basic and generic. Could i be using something that's
already in the JDK? Or something more like a
Callable-that-takes-a-parameter?

I know there's FileFilter and FilenameFilter, but those are too specific,
because of the File argument.

I know there's a Predicate in one of the collections add-on libraries
(Apache or Google, i forget which), which suggests that there isn't
something like this in the base library, but i thought i'd ask.

Thanks,
tom
 
D

Daniel Pitts

Hi chaps,

I just wrote this interface:

public interface Filter<T> {
boolean accept(T obj);
}

That seems awfully basic and generic. Could i be using something that's
already in the JDK? Or something more like a
Callable-that-takes-a-parameter?

I know there's FileFilter and FilenameFilter, but those are too
specific, because of the File argument.

I know there's a Predicate in one of the collections add-on libraries
(Apache or Google, i forget which), which suggests that there isn't
something like this in the base library, but i thought i'd ask.
There is in Apache Commons, I believe. I don't think there is one in
the Standard Java API. Even if there were, nothing uses it (there is no
removeIf method anywhere, no copyIf, etc...)
 
S

Stefan Ram

Tom Anderson said:
That seems awfully basic and generic.

I agree. I have defined such general interfaces in the ram.jar,
but you are right that such interfaces are especially useful
when defined in the standard library. I have defined, for example:

public interface Acceptor /* de.dclj.ram.Acceptor */ < Type >
{ public void accept( final Type datum ); }

public interface Add /* de.dclj.ram.Add */< Domain >
{ public void add( final Domain value ); }

public interface Advanceable /* de.dclj.ram.Advanceable */
{ /* Advance to the next state.
The initial state is the state before the first call to this. */
void advance(); }

public interface Calculation /* de.dclj.ram.Calculation */<R,T>
{ R of( T t ); }

public interface Contains /* de.dclj.ram.Contains */
< Domain >
{ boolean contains( Domain value ); }

and so on ...

Sun did not seem to get this idea.
 
A

Arne Vajhøj

I just wrote this interface:

public interface Filter<T> {
boolean accept(T obj);
}

That seems awfully basic and generic. Could i be using something that's
already in the JDK?

Nope.

The problem is not so much the interface as getting
an extra parameter added to a gazillion methods to
be able to use it generally.

Arne
 
T

Tom Anderson

I agree. I have defined such general interfaces in the ram.jar,
but you are right that such interfaces are especially useful
when defined in the standard library. I have defined, for example:

public interface Acceptor /* de.dclj.ram.Acceptor */ < Type >
{ public void accept( final Type datum ); }

public interface Add /* de.dclj.ram.Add */< Domain >
{ public void add( final Domain value ); }

public interface Advanceable /* de.dclj.ram.Advanceable */
{ /* Advance to the next state.
The initial state is the state before the first call to this. */
void advance(); }

public interface Calculation /* de.dclj.ram.Calculation */<R,T>
{ R of( T t ); }

public interface Contains /* de.dclj.ram.Contains */
< Domain >
{ boolean contains( Domain value ); }

and so on ...

Sun did not seem to get this idea.

Indeed. I think this is a path which you can go too far down, but there
are a basic set of single-method interfaces which would be useful:

void run()
T call()
void visit(T obj)
boolean accept(T obj)
T reduce(T a, T b)
T combine(U a, V b)
T map(U obj)

As Arne implies, they would derive much of their value from being used by
other classes throughout the standard library, and that would be a very
painful thing to retrofit.

tom
 
D

Daniel Pitts

As Arne implies, they would derive much of their value from being used
by other classes throughout the standard library, and that would be a
very painful thing to retrofit.
Retrofit, maybe, but adding methods to the Collections class, or
creating an external class, would not be that painful.
 
T

Tom Anderson

Retrofit, maybe, but adding methods to the Collections class, or creating an
external class, would not be that painful.

True. Not enormously satisfying, though. You could define a subinterface
of each of the collection interfaces which adds the new methods, then make
the AbstractWhateverCollection classes implement those on top of the
existing methods. That would compatibly and usefully add support.
Something similar was done with NavigableMap and relatives.

tom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top