117

In Java 8's java.util.function package, we have:

  • Function: Takes one argument, produces one result.
  • Consumer: Takes one argument, produces nothing.
  • Supplier: Takes no argument, produces one result.
  • ...: Other cases handling primitives, 2 arguments, etc...

But I need to handle the "takes no argument, produces nothing" case. There is nothing for this in java.util.function.

So, the question is: What is the name of 'a function that takes no argument and returns nothing'?

In Java 8, its definition would be:

@FunctionalInterface
public interface InsertANameHere {
    void execute();
}

Executor already exists and has another purpose : "An object that executes submitted Runnable tasks". The signature doesn't match (execute(Runnable):void) and is not even a functional interface.

Runnable exists, but it is strongly linked to the threading context:

  • The package is java.lang, not java.util.function.
  • The Javadoc states : "The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread".
  • The name "Runnable" suggest some running code inside a thread.
Nicolapps
  • 103
superbob
  • 1,342
  • 2
  • 8
  • 11

3 Answers3

82

Java's choice to do it that way with a separate name for every arity was not exactly worth emulating. However, if you must for the sake of consistency, or if you're writing very generic library code, Konrad's suggestions are good. I might throw Procedure into the ring.

Using a pseudo-functional paradigm doesn't mean normal naming principles should go out the window. Interfaces should almost always be named after what they do, not after some generic syntactic idea. If the functions are placed into an undo stack, they should be named UndoFunction. If they are called from GUI events, they should be named GUIEventHandler.

Karl Bielefeldt
  • 148,830
51

In the java world, it is called Runnable. In the C# world, it is called Action.

But, there is a better name which nicely fits within a larger view of things.

The larger view of things comes later, when you decide that besides the functional interface with a parameterless void method you also need another interface with a parameterless method that returns a generic value; and once you have those two, I guarantee to you that you will need additional versions of each, accepting one, two, or more generic arguments. When that happens, you will want the names of all those interfaces to be isomorphic and correspondent with each other.

So, in Java I have my own set of functional interfaces that I call Procedures, defined as follows:

public interface Procedure
{
    void invoke();
}

public interface Procedure1<T1>
{
    void invoke( T1 argument1 );
}


public interface Procedure2<T1>
{
    void invoke( T1 argument1, T2 argument2 );
}

... (you get the picture.)

And I also have a similar set of interfaces called Functions, defined in a similar way, with the first generic parameter being the return type:

public interface Function<R>
{
    R invoke();
}

public interface Function1<R,T1>
{
    R invoke( T1 argument1 );
}


public interface Function2<R,T1,T2>
{
    R invoke( T1 argument1, T2 argument2 );
}

... (similar picture.)

(C# already does exactly that with Func and Action. The names they have chosen are not ideal, but they are not bad enough to warrant replacing them with my preferred names.)

So, my point here is that Procedure is a very good name because it nicely fits within a larger view of things, and this is something that you will inevitably run into.

NOTE: I basically do agree with Karl Bielefeldt's assertion that "normal naming principles should [not] go out the window" and that "Interfaces should almost always be named after what they do, not after some generic syntactic idea." But note that even he allows for "almost always". Sometimes there is a need for (essentially anonymous) procedures and functions, and that's what the OP is asking, and that's what I am answering.

Amendment 2017-11-10:

You might ask, why Function1<R,T1> instead of Function1<T1,R>? It could go either way, but I have a preference for return values on the left because I like to follow the 'convert-from' (destination-from-source) naming convention as opposed to the 'convert-to' (source-to-destination) convention. (Which is more of an accident than a convention, really, in the sense that most probably, nobody ever gave it any thought, because if they had given it any thought at all they would have arrived at the 'convert-from' convention.)

You can read about this in Joel Spolksy - Making Wrong Code Look Wrong.

It is a very long article, which I recommend reading in its entirety, but if you want to jump straight to the case at hand, search for 'TypeFromType'.

To give you the TL;DR, the idea is that the following:

myint = intFromStr( mystr )

is much better than the following:

myint = strToInt( mystr )

because in the first case the names of the types are close to the associated values, so you can easily see that the 'int' matches with the 'int' and the 'str' matches with the 'str'.

So, by extension, I tend to order things in the way they are going to appear in code.

Mike Nakis
  • 32,803
19

Why not Command? Given that it takes no data and returns no data, but assuming that calling it causes some effect (otherwise it would be rather pointless really), I imagine that's roughly the only thing it can do - fire an action, make something happen.

Speaking of which, there's also a generic Action delegate in .NET. Unlike Java's Consumer it can take from 0 to 16 arguments; in other words, the simpliest version of it takes none - see MSDN.

And since the name doesn't imply there's anything to "consume", it also seems like a good name choice.

Konrad Morawski
  • 9,768