chen870647924 / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

Runnables.emptyRunnable() #880

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Following the Null Object design pattern, it would be useful to have a no-op 
runnable. This is similar to Collections.emptyCollection().

Original issue reported on code.google.com by cow...@bbs.darktech.org on 20 Jan 2012 at 4:07

GoogleCodeExporter commented 9 years ago
Do you have a use case in mind?  

Original comment by wasserman.louis on 20 Jan 2012 at 4:10

GoogleCodeExporter commented 9 years ago
I have:

  Runnable undo = ...;

which is the Runnable the application should run if the user hits the undo 
button. In my case, I only allow users to undo once and they could click the 
button from different screens. So depending on what action they ran last I need 
to run a different undo operation. Initially undo should be equal to 
Runnables.emptyRunnable().

Original comment by cow...@bbs.darktech.org on 20 Jan 2012 at 4:50

GoogleCodeExporter commented 9 years ago
I accept that something along the lines of Runnables.emptyRunnable() is the 
best solution to your use case.

I'm a bit hesitant to endorse the introduction of a Runnables utility class for 
the sake of one method, but I can think of a few more useful runnable utility 
methods -- convert a Runnable to a Callable with the specified return value 
(like the FutureTask tools do internally), and the like.

Original comment by wasserman.louis on 20 Jan 2012 at 4:55

GoogleCodeExporter commented 9 years ago
j.u.c has the Runnable->Callable method already.

http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html

I suspect we won't end up adding this, just because it's so easy to write 
yourself, but we'll see.

Original comment by cpov...@google.com on 20 Jan 2012 at 5:12

GoogleCodeExporter commented 9 years ago
See?  This is why I'm actually secretly a concurrency n00b.

Original comment by wasserman.louis on 20 Jan 2012 at 5:16

GoogleCodeExporter commented 9 years ago
I present 
http://docs.guava-libraries.googlecode.com/git-history/v11.0.1/javadoc/com/googl
e/common/util/concurrent/Callables.html#returning%28T%29 as a counter-argument 
to not adding stuff that "easy to write yourself".

I agree with Louis though, it would be easier to justify if we could find more 
Runnable-related functionality.

Original comment by cow...@bbs.darktech.org on 20 Jan 2012 at 7:04

GoogleCodeExporter commented 9 years ago
...Little as I hate to admit it -- and we do _try_ to avoid stuff that's "easy 
to write yourself," but it is unavoidably a judgement call -- that precedent 
seems to match this case pretty closely.

Original comment by wasserman.louis on 20 Jan 2012 at 7:07

GoogleCodeExporter commented 9 years ago
Yeah, Callables.returning is certainly borderline, too.  When the internal CL 
to add it was submitted, I think we let it sit for a week because no one had 
anything interesting to say for or against it.  We ended up adding it, and we 
could end up adding this, too.  I just doubt we'll have a compelling argument 
either way.

Original comment by cpov...@google.com on 20 Jan 2012 at 7:09

GoogleCodeExporter commented 9 years ago
Is the semantic-free Runnable interface really the best type to be using in the 
one use case we've heard?

Original comment by kevinb@google.com on 21 Jan 2012 at 3:54

GoogleCodeExporter commented 9 years ago
I think so?  You're passing an arbitrary callback that may or may not be called.

Another possible Runnables method: composing/sequencing Runnables.

Original comment by wasserman.louis on 21 Jan 2012 at 7:29

GoogleCodeExporter commented 9 years ago
From the information we have now, this seems way too rarely needed, especially 
since Callables.returning(anything) is there.

Original comment by kevinb@google.com on 30 Jan 2012 at 6:32

GoogleCodeExporter commented 9 years ago
I'm not sure I'm adding to this discussion, and even if so it's probably 
irrelevant, but accepting Runnable is a common API decision, and the reigning 
idiom for passing an empty runnable is passing 'null'.

Having a standard convenience for an empty runnable may help reverse this trend.

Original comment by ori...@gmail.com on 10 Oct 2013 at 7:04

GoogleCodeExporter commented 9 years ago
It looks like this has been added in Guava 16:

com.google.common.util.concurrent.Runnables.doNothing()

Original comment by wes...@cutterslade.ca on 7 Mar 2014 at 9:55

GoogleCodeExporter commented 9 years ago
Yay! Thanks for the head's up :)

Original comment by cow...@bbs.darktech.org on 7 Mar 2014 at 11:27

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 8 Mar 2014 at 3:35

GoogleCodeExporter commented 9 years ago
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:14

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08