«

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

--
an expertly crafted mix of practical decision-making and drunken shouting

On 6/23/2010 1:45 AM, Tom Anderson wrote:
> 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...)
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Tom Anderson <> writes:
>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.

On 23-06-2010 04:45, Tom Anderson wrote:
> 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

On Wed, 23 Jun 2010, Stefan Ram wrote:

> Tom Anderson <> writes:
>> 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.

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

--
How's it going to end?

On 6/24/2010 9:54 AM, Tom Anderson wrote:
> 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.


--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

On Thu, 24 Jun 2010, Daniel Pitts wrote:

> On 6/24/2010 9:54 AM, Tom Anderson wrote:
>> 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.

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

--
Thinking about it, history begins now -- sarah