11 Mar
2024
11 Mar
'24
1:35 p.m.
Issue #20319 has been updated by Eregon (Benoit Daloze).
jeremyevans0 (Jeremy Evans) wrote in #note-4:
I disagree. If you do not freeze the object's
singleton class, then you can define or undefine any method in the singleton class, which
is almost the same as being able to modify the object (from a Ruby perspective, not a C
perspective).
One can still define or undefine any method in one of the ancestors (except the singleton
class), or use `prepend`/`include` on any of these or even `refine` to change the behavior
of that object.
Freezing the singleton class achieves very little IMO and is inconsistent with
`Kernel#freeze` being a shallow freeze (that is, only freeze the immediate object, not
other objects, which AFAIK holds for all other cases).
----------------------------------------
Bug #20319: Singleton class is being frozen lazily in some cases
https://bugs.ruby-lang.org/issues/20319#change-107172
* Author: andrykonchin (Andrew Konchin)
* Status: Open
* ruby -v: 3.2.2
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
I've noticed suspicious behaviour (it doesn't affect anything in practice for me
though) when an object becomes frozen only its own singleton class becomes frozen
immediately.
A singleton class of the object immediate singleton class becomes frozen lazily after
`#singleton_class` method call:
```ruby
o = Object.new
klass = o.singleton_class.singleton_class
o.freeze
puts klass.frozen? # false <== here we expect true
puts o.singleton_class.singleton_class.frozen? # true
puts klass.frozen? # true
```
I would expect all created (and visible to user) singleton classes in an object singleton
classes chain to become frozen immediately when the object gets frozen.
--
https://bugs.ruby-lang.org/