Suggestion: Implement `freeze_values` instance method on collection-like classes.
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
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?
Updated by keithrbennett (Keith Bennett) about 2 months ago
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
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.
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.)