iconara / ione
100%
master: 99%

LAST BUILD BRANCH: v1.2.4
DEFAULT BRANCH: master
Repo Added
Files 12
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH destructive-future-combinators
branch: destructive-future-combinators
CHANGE BRANCH
x

164

push

travis-ci

Gustav Munkby 
Proof-of-concept destructive future combinators

Implement destructive versions of the combinators, that updates the
existing future rather than creating a new one. The new combinators
ought to be thread-safe, but interleaving destructive updates might
produce counter-intuitive results sometimes. However, the common use
case seems to be synchronous construction of an asynchronous future
chain, in which case these combinators might reduce memory footprint
and call stack depth.

This is made possible by not resolving a future until after the
callbacks have completed. This is obviously a backwards-incompatible
change, as it causes any code with a `#value` in a callback to hang
indefinitely.

An obvious alternative would be to treat "transformations" and
"callbacks" separately, but I tried to avoid introducing further
bookkeeping surrounding the callbacks. 

Another advantage of keeping callbacks and transformations in a list
is that synchronous transformations behave as expected. That is, if
you add a listener before and after a `map!` is applied, the first
callback will receive the unmapped value, and the second callback will
receive the transformed value.

The future chaining transformations (`flat_map`, `then` and `fallback`)
requires some way to stop the listener dispatch in order to implement
the destructive versions. Here, this is accomplished by using the
return value of the listener callback. There is probably a better way
to get the same effect. To avoid breaking existing callbacks, this was
separated into the `on_complete!` callback.

To avoid too much code duplication, the non-destructive operation `foo`
is implemented using `dup.foo!`, similar to how non-destructive array
operations can be implemented. Not quite sure `dup` is the right name
for the newly constructed future (observing on the original), though.

I made some minor adjustments to the remaining code to get the future
specs to pass, but these are probably not 100% correct.

I have ... (continued)

2389 of 2393 relevant lines covered (99.83%)

9484.67 hits per line

Relevant lines Covered
2393 RELEVANT LINES 2389 COVERED LINES
9484.67 HITS PER LINE
Source Files on destructive-future-combinators
Detailed source file information is not available for this build.

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
164 destructive-future-combinators Proof-of-concept destructive future combinators Implement destructive versions of the combinators, that updates the existing future rather than creating a new one. The new combinators ought to be thread-safe, but interleaving destructive updates ... push Gustav Munkby travis-ci pending completion  
See All Builds (272)