Closed GoogleCodeExporter closed 9 years ago
Do you have a use case in mind?
Original comment by wasserman.louis
on 20 Jan 2012 at 4:10
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
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
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
See? This is why I'm actually secretly a concurrency n00b.
Original comment by wasserman.louis
on 20 Jan 2012 at 5:16
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
...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
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
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
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
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
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
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
Yay! Thanks for the head's up :)
Original comment by cow...@bbs.darktech.org
on 7 Mar 2014 at 11:27
Original comment by cgdecker@google.com
on 8 Mar 2014 at 3:35
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
Original comment by cgdecker@google.com
on 3 Nov 2014 at 9:08
Original issue reported on code.google.com by
cow...@bbs.darktech.org
on 20 Jan 2012 at 4:07