bindable_block 0.0.5 → 0.0.5.1
Sign up to get free protection for your applications and to get access to all the features.
- data/README.md +39 -0
- data/README.mountain_berry_fields.md +43 -0
- data/lib/bindable_block/version.rb +1 -1
- metadata +2 -2
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:
|
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-
|
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.
|