From: daniel@...42.com Date: 2020-10-21T13:28:51+00:00 Subject: [ruby-core:100474] [Ruby master Feature#17145] Ractor-aware `Object#deep_freeze` Issue #17145 has been updated by Dan0042 (Daniel DeLorme). marcandre (Marc-Andre Lafortune) wrote in #note-22: > I've been wanting for a long while to propose an API for caching methods, and that could be made Ractor compatible and would resolve most of these cases, but maybe it's too early to consider it? +1 The `@var ||= expr` idiom works well for most cases of memoization, but breaks down for nil values and frozen objects. It's easy enough to handle these cases with a small memoization library (and in fact I do so in my code). But since frozen objects are now going to be everywhere because of ractor, I think it's time to introduce this in core. ---------------------------------------- Feature #17145: Ractor-aware `Object#deep_freeze` https://bugs.ruby-lang.org/issues/17145#change-88093 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Priority: Normal ---------------------------------------- I'd like to propose `Object#deep_freeze`: Freezes recursively the contents of the receiver (by calling `deep_freeze`) and then the receiver itself (by calling `freeze`). Values that are shareable via `Ractor` (e.g. classes) are never frozen this way. ```ruby # freezes recursively: ast = [:hash, [:pair, [:str, 'hello'], [:sym, :world]]].deep_freeze ast.dig(1, 1) # => [:str, 'hello'] ast.dig(1, 1).compact! # => FrozenError # does not freeze classes: [[String]].deep_freeze String.frozen? # => false # calls `freeze`: class Foo def freeze build_cache! puts "Ready for freeze" super end # ... end [[[Foo.new]]].deep_freeze # => Outputs "Ready for freeze" ``` I think a variant `deep_freeze!` that raises an exception if the result isn't Ractor-shareable would be useful too: ```ruby class Fire def freeze # do not call super end end x = [Fire.new] x.deep_freeze! # => "Could not be deeply-frozen: #" ``` -- https://bugs.ruby-lang.org/ Unsubscribe: