# Futures in Ruby

**URL:** <https://www.ruby-forum.com/t/futures-in-ruby/51984>\
**Category:** Ruby\
**Created:** [January 9, 2006, 10:24pm UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984 "2006-01-09T22:24:58Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [January 9, 2006, 10:24pm UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984/1 "2006-01-09T22:24:58Z")

</div>

I was looking at the Io documentation, just to see what the language  
looked like and saw the asynchronous support, pretty cool. Then it  
sort of dawned on my how Futures worked, no it isn’t all that  
complicated, but I it’s amazing what you can avoid thinking about. Who  
knows, I think looking into the gaze of a new language, and reading too  
much of \_why’s Redhanded is likely to provide random inspiration. So  
here is a quick implementation of transparent futures in ruby. Two  
questions:

1. Is it worth tossing this on RubyForge or some such place?
2. I’d like to use BlankSlate, but it’s part of Builder, but it seems  
silly for this to depend on all of the Builder gem, so for demo  
purposes BlankSlate is pasted in and taken out of the Builder  
namespace.

To try it out do something like this:  
require ‘future’  
f = Future.new{sleep 5; 10} # Returns immediately  
f + 1 # 11 after a pause

.adam

#–

# Copyright 2004 by Jim W. (removed\_email\_address@domain.invalid).

# All rights reserved.

# Permission is granted for use, copying, modification, distribution,

# and distribution of modified versions of this work as long as the

# above copyright notice is included.

#++

# BlankSlate provides an abstract base class with no predefined

# methods (except for \_\_send\_\_ and \_\_id\_\_).

# BlankSlate is useful as a base class when writing classes that

# depend upon method\_missing (e.g. dynamic proxies).

class BlankSlate #:nodoc:  
class \<\< self  
def hide(name)  
undef\_method name if  
instance\_methods.include?(name.to\_s) and  
name !~ /^(\_\_|instance\_eval)/  
end  
end

instance\_methods.each { |m| hide(m) }  
end

# Since Ruby is very dynamic, methods added to the ancestors of

# BlankSlate _after BlankSlate is defined_ will show up in the

# list of available BlankSlate methods. We handle this by defining a

hook in the Object and Kernel classes that will hide any defined  
module Kernel #:nodoc:  
class \<\< self  
alias\_method :blank\_slate\_method\_added, :method\_added  
def method\_added(name)  
blank\_slate\_method\_added(name)  
return if self != Kernel  
BlankSlate.hide(name)  
end  
end  
end

class Object #:nodoc:  
class \<\< self  
alias\_method :blank\_slate\_method\_added, :method\_added  
def method\_added(name)  
blank\_slate\_method\_added(name)  
return if self != Object  
BlankSlate.hide(name)  
end  
end  
end

# Future

# Adam S. fooling around on 2006-01-07

class Future \< BlankSlate  
def initialize(\*args, &block)  
@\_\_thread = Thread.new do  
@\_\_value = block.call(\*args)  
end  
end

```
def __getobj__
	if @__thread
		@__thread.join
		@__thread = nil
	end
	@__value
end

def method_missing(sym, *args, &block)
	__getobj__.send sym, *args, &block
end

def inspect
	(@__thread) ? "Unevaluated Future on #{@__thread.inspect}" :

```

@\_\_value.inspect  
end  
end

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [January 9, 2006, 10:37pm UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984/2 "2006-01-09T22:37:07Z")

</div>

On 1/9/06, Adam S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> So here is a quick implementation of transparent futures in ruby.

Also see [http://jacob.fugal.net/blog/4](http://jacob.fugal.net/blog/4)

There are some significant differences in implementation between mine  
and yours, particularly that yours is a mix between futures and  
asyncs. If I understand correctly (which I may not), the body of a  
future shouldn’t be executed until requested. This is important in  
that the body of the future may have side effects that shouldn’t be  
invoked until requested. Thus starting the thread that calculates the  
future right away isn’t quite correct. But as a mix between futures  
and asyncs, I can see how it might be useful.

Jacob F.

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [January 10, 2006, 12:11am UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984/3 "2006-01-10T00:11:06Z")

</div>

Interesting, I wasn’t aware of that difference. My assumption was that  
asynchs in Io were just asynchronous calls that required no result  
which is quite likely wrong. I mostly went off of things I’ve gleaned  
from the Java Concurrency package:  
[http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html](http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html)

Your implementation appears to be more like mental’s Promises  
[http://www.ruby-forum.com/topic/48121](http://www.ruby-forum.com/topic/48121)

They’re all subtly different, handy constructs 🙂  
.adam

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [January 10, 2006, 3:45am UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984/4 "2006-01-10T03:45:11Z")

</div>

I think the semantics in this case are just semantics. The difference  
between a “future” being executed on request and being executed in the  
background is merely the difference between two implementations of the  
executor service the task was run under (another implementation might  
even calculate the future up-front.)

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [January 10, 2006, 5:21am UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984/5 "2006-01-10T05:21:41Z")

</div>

On 1/9/06, Trejkaz [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I think the semantics in this case are just semantics. The difference  
> between a “future” being executed on request and being executed in the  
> background is merely the difference between two implementations of the  
> executor service the task was run under (another implementation might  
> even calculate the future up-front.)

Not really. As I said, there may be side-effects that shouldn’t occur  
until the value is actually processed. As far as delayed effects, true  
this wouldn’t matter as much. But say the future wraps a  
mathematically intensive operation that may or may not be used in the  
program. I certainly want to put off that operation until I know I  
need it. To be clear, I’m not arguing that this interpretation is more  
correct – an implementation that calculates the future as soon as  
possible or even in advance can be just as useful. My claim is only  
that the difference _is_ significant.

Jacob F.

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [January 10, 2006, 4:44pm UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984/6 "2006-01-10T16:44:08Z")

</div>

Quoting A. Sanderson [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> So here is a quick implementation of transparent futures in ruby.

FWIW, I’ve done something similar:

[http://moonbase.rydia.net/software/lazy.rb](http://moonbase.rydia.net/software/lazy.rb)

-mental

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [January 10, 2006, 7:51pm UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984/7 "2006-01-10T19:51:45Z")

</div>

On Jan 10, 2006, at 7:41 AM, removed\_email\_address@domain.invalid wrote:

> FWIW, I’ve done something similar:
> 
> [http://moonbase.rydia.net/software/lazy.rb](http://moonbase.rydia.net/software/lazy.rb)
> 
> -mental

popular thing to hack on: [http://kasparov.skife.org/blog/src/futures-](http://kasparov.skife.org/blog/src/futures-)  
two.html

=)

-Brian

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [January 10, 2006, 8:25pm UTC](https://www.ruby-forum.com/t/futures-in-ruby/51984/8 "2006-01-10T20:25:07Z")

</div>

Quoting Brian McCallister [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> two.html  
> It’s one of those ideas whose time has come; I fully intend to  
> submit an RCR after a couple more releases, when the API is more  
> refined.

No aeroplanes bursting from the hedgerows to-day!

-mental