21 Jan
2023
21 Jan
'23
10:04 a.m.
Issue #19362 has been reported by zverok (Victor Shepelev).
----------------------------------------
Bug #19362: #dup on Proc doesn't call initialize_dup
https://bugs.ruby-lang.org/issues/19362
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In #17545, `#dup` had changed to create an instance of the subclass.
It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard
classes.
```ruby
class MyAry < Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyString < String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyProc < Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
MyString.new('test').dup # prints MyString, "test"
MyAry.new(['test']).dup # prints MyAry, ["test"]
MyProc.new { 'test' }.dup # doesn't print anything
```
This makes the change in #17545 useless: while inheriting from core classes is indeed
marginal, one of author's intention might be carrying additional information with the
Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this
information.
It seems that actually `#initialize_dup` is also invoked on the core classes themselves,
but ignored on `Proc`.
```ruby
class Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
'test'.dup # prints String, "test"
['test'].dup # prints Array, ["test"]
Proc.new { 'test' }.dup # doesn't print anything
```
Which is an even more marginal problem but still an inconsistency.
--
https://bugs.ruby-lang.org/
21 Jan
21 Jan
6:47 p.m.
New subject: [ruby-core:111961] [Ruby master Bug#19362] #dup on Proc doesn't call initialize_dup
Issue #19362 has been updated by nobu (Nobuyoshi Nakada).
While `String.allocate` and `Array.allocate` are defined, `Proc.allocate` is not.
What do you expect as the argument of `Proc#initialize_copy`?
----------------------------------------
Bug #19362: #dup on Proc doesn't call initialize_dup
https://bugs.ruby-lang.org/issues/19362#change-101394
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In #17545, `#dup` had changed to create an instance of the subclass.
It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard
classes.
```ruby
class MyAry < Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyString < String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyProc < Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
MyString.new('test').dup # prints MyString, "test"
MyAry.new(['test']).dup # prints MyAry, ["test"]
MyProc.new { 'test' }.dup # doesn't print anything
```
This makes the change in #17545 useless: while inheriting from core classes is indeed
marginal, one of author's intention might be carrying additional information with the
Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this
information.
It seems that actually `#initialize_dup` is also invoked on the core classes themselves,
but ignored on `Proc`.
```ruby
class Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
'test'.dup # prints String, "test"
['test'].dup # prints Array, ["test"]
Proc.new { 'test' }.dup # doesn't print anything
```
Which is an even more marginal problem but still an inconsistency.
--
https://bugs.ruby-lang.org/
22 Jan
22 Jan
5:03 a.m.
New subject: [ruby-core:111963] [Ruby master Bug#19362] #dup on Proc doesn't call initialize_dup
Issue #19362 has been updated by zverok (Victor Shepelev).
What do you expect as self of `Proc#initialize_dup`?
@nobu "the current proc object", like in any `initialize[...]`. I am not sure I
understand why is it impossible. From layman's point of view, those two should work
the same way:
```ruby
class TaggedString < String
attr_reader :tag
def initialize(val, tag:)
super(val)
@tag = tag
end
def initialize_dup(other)
super
@tag = other.tag
end
end
class TaggedProc < Proc
attr_reader :tag
def initialize(tag, &block)
super(&block)
@tag = tag
end
def initialize_dup(other)
super
@tag = other.tag
end
end
s = TaggedString.new('test', tag: 'foo')
p s.tag #=> 'foo'
p s.dup.tag #=> 'foo'
t = TaggedProc.new('test') { }
p t.tag #=> 'test'
p t.dup.tag #=> expected 'test', got nil
```
Otherwise, I am not sure what's the semantics of `Proc#dup` and how it is supposed to
be used.
And if it isn't supposed to, it might make sense to prohibit its usage or at least
document the quirks?..
----------------------------------------
Bug #19362: #dup on Proc doesn't call initialize_dup
https://bugs.ruby-lang.org/issues/19362#change-101397
* Author: zverok (Victor Shepelev)
* Status: Feedback
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In #17545, `#dup` had changed to create an instance of the subclass.
It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard
classes.
```ruby
class MyAry < Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyString < String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyProc < Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
MyString.new('test').dup # prints MyString, "test"
MyAry.new(['test']).dup # prints MyAry, ["test"]
MyProc.new { 'test' }.dup # doesn't print anything
```
This makes the change in #17545 useless: while inheriting from core classes is indeed
marginal, one of author's intention might be carrying additional information with the
Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this
information.
It seems that actually `#initialize_dup` is also invoked on the core classes themselves,
but ignored on `Proc`.
```ruby
class Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
'test'.dup # prints String, "test"
['test'].dup # prints Array, ["test"]
Proc.new { 'test' }.dup # doesn't print anything
```
Which is an even more marginal problem but still an inconsistency.
--
https://bugs.ruby-lang.org/
23 Jan
23 Jan
3:22 a.m.
New subject: [ruby-core:111987] [Ruby master Bug#19362] #dup on Proc doesn't call initialize_dup
Issue #19362 has been updated by nobu (Nobuyoshi Nakada).
Status changed from Feedback to Open
https://github.com/ruby/ruby/pull/7178
----------------------------------------
Bug #19362: #dup on Proc doesn't call initialize_dup
https://bugs.ruby-lang.org/issues/19362#change-101425
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In #17545, `#dup` had changed to create an instance of the subclass.
It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard
classes.
```ruby
class MyAry < Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyString < String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyProc < Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
MyString.new('test').dup # prints MyString, "test"
MyAry.new(['test']).dup # prints MyAry, ["test"]
MyProc.new { 'test' }.dup # doesn't print anything
```
This makes the change in #17545 useless: while inheriting from core classes is indeed
marginal, one of author's intention might be carrying additional information with the
Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this
information.
It seems that actually `#initialize_dup` is also invoked on the core classes themselves,
but ignored on `Proc`.
```ruby
class Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
'test'.dup # prints String, "test"
['test'].dup # prints Array, ["test"]
Proc.new { 'test' }.dup # doesn't print anything
```
Which is an even more marginal problem but still an inconsistency.
--
https://bugs.ruby-lang.org/
9 Feb
9 Feb
2:30 a.m.
New subject: [ruby-core:112298] [Ruby master Bug#19362] #dup on Proc doesn't call initialize_dup
Issue #19362 has been updated by zverok (Victor Shepelev).
@nobu Thanks! Will this PR be merged? (I secretly hoped to have it in 3.2.1 :)))
----------------------------------------
Bug #19362: #dup on Proc doesn't call initialize_dup
https://bugs.ruby-lang.org/issues/19362#change-101733
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In #17545, `#dup` had changed to create an instance of the subclass.
It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard
classes.
```ruby
class MyAry < Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyString < String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyProc < Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
MyString.new('test').dup # prints MyString, "test"
MyAry.new(['test']).dup # prints MyAry, ["test"]
MyProc.new { 'test' }.dup # doesn't print anything
```
This makes the change in #17545 useless: while inheriting from core classes is indeed
marginal, one of author's intention might be carrying additional information with the
Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this
information.
It seems that actually `#initialize_dup` is also invoked on the core classes themselves,
but ignored on `Proc`.
```ruby
class Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
'test'.dup # prints String, "test"
['test'].dup # prints Array, ["test"]
Proc.new { 'test' }.dup # doesn't print anything
```
Which is an even more marginal problem but still an inconsistency.
--
https://bugs.ruby-lang.org/
11:56 p.m.
New subject: [ruby-core:112328] [Ruby master Bug#19362] #dup on Proc doesn't call initialize_dup
Issue #19362 has been updated by nobu (Nobuyoshi Nakada).
I'm not sure if this is a bug or intentional.
Please add this to [Misc #19429].
----------------------------------------
Bug #19362: #dup on Proc doesn't call initialize_dup
https://bugs.ruby-lang.org/issues/19362#change-101772
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In #17545, `#dup` had changed to create an instance of the subclass.
It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard
classes.
```ruby
class MyAry < Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyString < String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyProc < Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
MyString.new('test').dup # prints MyString, "test"
MyAry.new(['test']).dup # prints MyAry, ["test"]
MyProc.new { 'test' }.dup # doesn't print anything
```
This makes the change in #17545 useless: while inheriting from core classes is indeed
marginal, one of author's intention might be carrying additional information with the
Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this
information.
It seems that actually `#initialize_dup` is also invoked on the core classes themselves,
but ignored on `Proc`.
```ruby
class Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
'test'.dup # prints String, "test"
['test'].dup # prints Array, ["test"]
Proc.new { 'test' }.dup # doesn't print anything
```
Which is an even more marginal problem but still an inconsistency.
--
https://bugs.ruby-lang.org/
8 Mar
8 Mar
10:16 p.m.
New subject: [ruby-core:112761] [Ruby master Bug#19362] #dup on Proc doesn't call initialize_dup
Issue #19362 has been updated by matz (Yukihiro Matsumoto).
Accepted, mostly for the sake of consistency. As a general suggestion, making subclasses
from built-in classes is not a good idea in Ruby, though.
Matz.
----------------------------------------
Bug #19362: #dup on Proc doesn't call initialize_dup
https://bugs.ruby-lang.org/issues/19362#change-102254
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In #17545, `#dup` had changed to create an instance of the subclass.
It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard
classes.
```ruby
class MyAry < Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyString < String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyProc < Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
MyString.new('test').dup # prints MyString, "test"
MyAry.new(['test']).dup # prints MyAry, ["test"]
MyProc.new { 'test' }.dup # doesn't print anything
```
This makes the change in #17545 useless: while inheriting from core classes is indeed
marginal, one of author's intention might be carrying additional information with the
Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this
information.
It seems that actually `#initialize_dup` is also invoked on the core classes themselves,
but ignored on `Proc`.
```ruby
class Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
'test'.dup # prints String, "test"
['test'].dup # prints Array, ["test"]
Proc.new { 'test' }.dup # doesn't print anything
```
Which is an even more marginal problem but still an inconsistency.
--
https://bugs.ruby-lang.org/
25 Oct
25 Oct
10:21 p.m.
New subject: [ruby-core:115175] [Ruby master Bug#19362] #dup on Proc doesn't call initialize_dup
Issue #19362 has been updated by nobu (Nobuyoshi Nakada).
I've forgot this, but isn't this a feature require but not a bug?
----------------------------------------
Bug #19362: #dup on Proc doesn't call initialize_dup
https://bugs.ruby-lang.org/issues/19362#change-105087
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In #17545, `#dup` had changed to create an instance of the subclass.
It, though, doesn't invoke `initialize_dup` of the subclass, unlike other standard
classes.
```ruby
class MyAry < Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyString < String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class MyProc < Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
MyString.new('test').dup # prints MyString, "test"
MyAry.new(['test']).dup # prints MyAry, ["test"]
MyProc.new { 'test' }.dup # doesn't print anything
```
This makes the change in #17545 useless: while inheriting from core classes is indeed
marginal, one of author's intention might be carrying additional information with the
Proc instance, and bypassing `#initialize_dup` makes it impossible to maintain this
information.
It seems that actually `#initialize_dup` is also invoked on the core classes themselves,
but ignored on `Proc`.
```ruby
class Array
def initialize_dup(...)
p(self.class, ...)
super
end
end
class String
def initialize_dup(...)
p(self.class, ...)
super
end
end
class Proc
def initialize_dup(...)
p(self.class, ...)
super
end
end
'test'.dup # prints String, "test"
['test'].dup # prints Array, ["test"]
Proc.new { 'test' }.dup # doesn't print anything
```
Which is an even more marginal problem but still an inconsistency.
--
https://bugs.ruby-lang.org/
207
days inactive
485
days old
7 comments
3 participants
participants (3)
-
matz (Yukihiro Matsumoto) -
nobu (Nobuyoshi Nakada) -
zverok (Victor Shepelev)