bindable_block 0.0.5 → 0.0.5.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
data/README.md CHANGED
@@ -12,6 +12,45 @@ greeter.bind(User.new "Josh").call # => "Welcome, Josh"
12
12
 
13
13
  [Here](https://github.com/JoshCheek/surrogate/blob/eb1d7f98a148c032f6d3ef1d8df8b703386f286d/lib/surrogate/options.rb#L32-34) is an example.
14
14
 
15
+ ## Where the abstraction leaks
16
+
17
+ Bindable block does something that isn't possible in Ruby.
18
+ It does this with black magick. Unfortunately, that abstraction
19
+ will leak in the case of return statements. Return statements in
20
+ blocks will return you from the containing method.
21
+
22
+ ```ruby
23
+ def meth
24
+ Proc.new { return 1 }.call
25
+ 2
26
+ end
27
+
28
+ meth # => 1
29
+ ```
30
+
31
+
32
+ Return statements in lambdas will return you from the lambda.
33
+
34
+ ```ruby
35
+ def meth
36
+ lambda { return 1 }.call
37
+ 2
38
+ end
39
+
40
+ meth # => 2
41
+ ```
42
+
43
+ You would expect a bindable block to continue to behave like the
44
+ former example, but it will actually behave like the latter example.
45
+
46
+ At present, I can only think of two ways to fix this:
47
+
48
+ 1) It might be possible to rewrite the AST with ripper.
49
+ 2) It is probably possible to write this in C.
50
+
51
+ Neither of these are high on my priority list.
52
+
53
+
15
54
  ## Installation
16
55
 
17
56
  Add this line to your application's Gemfile:
@@ -14,6 +14,49 @@ greeter.bind(User.new "Josh").call # => "Welcome, Josh"
14
14
 
15
15
  [Here](https://github.com/JoshCheek/surrogate/blob/eb1d7f98a148c032f6d3ef1d8df8b703386f286d/lib/surrogate/options.rb#L32-34) is an example.
16
16
 
17
+ ## Where the abstraction leaks
18
+
19
+ Bindable block does something that isn't possible in Ruby.
20
+ It does this with black magick. Unfortunately, that abstraction
21
+ will leak in the case of return statements. Return statements in
22
+ blocks will return you from the containing method.
23
+
24
+ ```ruby
25
+ <% test 'proc behaviour', with: :magic_comments do %>
26
+ def meth
27
+ Proc.new { return 1 }.call
28
+ 2
29
+ end
30
+
31
+ meth # => 1
32
+ <% end %>
33
+ ```
34
+
35
+
36
+ Return statements in lambdas will return you from the lambda.
37
+
38
+ ```ruby
39
+ <% test 'lambda behaviour', with: :magic_comments do %>
40
+ def meth
41
+ lambda { return 1 }.call
42
+ 2
43
+ end
44
+
45
+ meth # => 2
46
+ <% end %>
47
+ ```
48
+
49
+ You would expect a bindable block to continue to behave like the
50
+ former example, but it will actually behave like the latter example.
51
+
52
+ At present, I can only think of two ways to fix this:
53
+
54
+ 1) It might be possible to rewrite the AST with ripper.
55
+ 2) It is probably possible to write this in C.
56
+
57
+ Neither of these are high on my priority list.
58
+
59
+
17
60
  ## Installation
18
61
 
19
62
  Add this line to your application's Gemfile:
@@ -1,3 +1,3 @@
1
1
  class BindableBlock
2
- VERSION = "0.0.5"
2
+ VERSION = "0.0.5.1"
3
3
  end
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: bindable_block
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.0.5
4
+ version: 0.0.5.1
5
5
  prerelease:
6
6
  platform: ruby
7
7
  authors:
@@ -9,7 +9,7 @@ authors:
9
9
  autorequire:
10
10
  bindir: bin
11
11
  cert_chain: []
12
- date: 2012-06-09 00:00:00.000000000 Z
12
+ date: 2012-06-18 00:00:00.000000000 Z
13
13
  dependencies: []
14
14
  description: instance_exec can't pass block arguments through. Use a bindable block
15
15
  instead.