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/