What is the name of a function that takes no argument and returns nothing? [closed]

Question

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.

Answer 1

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.

Answer 2

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 your parameterless void functional interface you also need to have similar functional interfaces that accept one, two, or more arguments, or that return a value. When that happens, you will want the names of all those entities 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 );
}

... (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 );
}

So, my point here is that Procedure is a very good name because it nicely fits within a larger view of things. If you later decide to have similar functional interfaces with methods that accept arguments or return a value, you will run into this.

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

I 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', but to give you the TL;DR, the idea is that myint = intFromStr( mystr ) is much better than 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.

Answer 3

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.