Issue #17627 has been updated by keithrbennett (Keith Bennett).


I don't think the `Ractor#make_shareable` method and the `shareable_constant_value` pragma address this issue, for a few reasons:

1) they do a recursive deep freeze; `freeze_values` is just for a single level freeze; that is, call `freeze` on the contained objects, such as an array's elements or a hash's values, and let those objects decide based on their freeze implementation how deep to go. Doing a deep_freeze can be risky, whereas freezing only one level down is much less so. This may not be sufficient freezing to be ractor-safe, but that is not necessarily the intention of `freeze_values`.

2) `Ractor#make_shareable` is ractor-specific, whereas there may be many other use cases not related to ractors that would require freezing the object's values. `Ractor#make_shareable` would be hard to find for a developer not using ractors and not familiar with them, who is looking for a way to freeze an object's values. In addition, `make_shareble` is less intention revealing than `freeze_values` when not used in the context of ractors.

3) the `shareable_constant_value` pragma only applies to constants, and applies to all constants in a file, whereas the kinds of places where `freeze_values` would likely be called go far beyond that one use case, and may not need to be called for all objects of the given type. For example, given two hashes having values that must not be changed, it would be helpful to freeze the values if it were passed all over the code base with a relatively long life, whereas this might not be necessary for a hash whose lifetime was limited to the method call in which it was created, and passed only to known safe methods. (Though even when passed to known safe methods, it might be better to freeze the values, given that gems and other code can monkey patch that method's calls.)


----------------------------------------
Feature #17627: Suggestion: Implement `freeze_values` instance method on collection-like classes.
https://bugs.ruby-lang.org/issues/17627#change-90413

* Author: keithrbennett (Keith Bennett)
* Status: Open
* Priority: Normal
----------------------------------------
Suggestion: Implement `freeze_values` instance method on collection-like classes.

By collection-like classes, I mean classes such as Array, Hash, Set, Struct, OpenStruct, and custom classes containing multiple objects.

There has been some discussion of a recursive `deep_freeze` method, and although it could be very useful, there are potential problems regarding unintended consequences, and guarding against these would make the implementation more complex.

This complexity could be greatly reduced if we limit the scope of the freeze to only one level, and have the new `freeze_values` method call `freeze`.

The implementation would be trivial, I think. For example:

```
class Array  # same for Set
  def freeze_values
    each(&:freeze)
  end
end

class Hash
  def freeze_values
    values.each(&:freeze)
  end
end
```

There would still be a risk that the programmer would call this when some values should not be frozen, but that risk would be smaller and more manageable.

Also, there are many cases in which these collections contain simple objects such as strings and numbers. In these cases, recursion would not be necessary or helpful.

Although it could be argued that the implementation is so trivial that it does not need a method implemented, I believe that:

1) the method would nevertheless simplify the task, encouraging freezing
2) the method name would be a higher level description of the operation, making the code more readable
3) custom classes could implement this contract in their own way, yielding the benefits of polymorphism

What do you think?




-- 
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>