[#77789] [Ruby trunk Feature#12012] Add Boolean method — prodis@...
Issue #12012 has been updated by Fernando Hamasaki de Amorim.
4 messages
2016/10/27
[ruby-core:77747] [Ruby trunk Bug#12861] super in a block can be either lexically or dynamically scoped depending on how the block is invoked
From:
alxtskrnk@...
Date:
2016-10-24 15:57:51 UTC
List:
ruby-core #77747
Issue #12861 has been updated by bug hit.
bug hit wrote:
> it would have to fail the same way instance_eval of the block (with super) fails when self is wrong (self has wrong type to call super in this context).
to expand on that, super normally binds to the method (class + method) lexically, so when it gets a self that's not compatible with its method binding it raises.
```ruby
class Class1
def self.bar(&block)
instance_eval(&block)
end
end
class Class2
def self.foo
Class1.bar do
super
end
end
end
Class2.foo #self has wrong type to call super in this context: Class (expected #<Class:Class2>)
```
This makes sense. But in a define_method scenario (are there others?), the same super keyword suddenly starts binding to the method dynamically. Such overloading of core characteristics of a given construct seems wrong.
----------------------------------------
Bug #12861: super in a block can be either lexically or dynamically scoped depending on how the block is invoked
https://bugs.ruby-lang.org/issues/12861#change-61050
* Author: bug hit
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v: ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
```ruby
class Class1
def self.foo
'foo'
end
def self.method1
'method1'
end
end
class Class2 < Class1
def self.foo
bar do
super()
end
end
def self.bar(&block)
a = block.()
define_singleton_method :method1, &block
b = send(:method1)
c = block.()
[a, b, c]
end
end
p Class2.foo # ["foo", "method1", "foo"]
```
It doesn't seem like a good idea for a given language construct to be either lexically or dynamically scoped, depending on how its surrounding block is invoked (which is not visible at the point of definition). I think it would be better if super were always lexically scoped, and a different keyword (dynamic_super) were always dynamically scoped
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>