[#100309] How to use backport custom field — Jun Aruga <jaruga@...>
Please allow my ignorance.
9 messages
2020/10/06
[#100310] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
IkJhY2twb3J0IGN1c3RvbSBmaWVsZCIgaXMgb25seSBhdmFpbGFibGUgZm9yIHRpY2tldHMgd2hv
[#100311] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/06
On Tue, Oct 6, 2020 at 4:44 PM NARUSE, Yui <[email protected]> wrote:
[#100314] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
VGhhbmsgeW91IGZvciBjb25maXJtYXRpb24uCkkgY2hlY2tlZCBhZ2FpbiBhbmQgdG8gZWRpdCBi
[#100322] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Tue, Oct 6, 2020 at 7:25 PM NARUSE, Yui <[email protected]> wrote:
[#100326] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/07
SSBhZGRlZCB5b3UgdG8gIlJlcG9ydGVyIiByb2xlIGluIHRoZSBwcm9qZWN0CgoyMDIw5bm0MTDm
[#100327] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Wed, Oct 7, 2020 at 1:42 PM NARUSE, Yui <[email protected]> wrote:
[ruby-core:100514] [Ruby master Feature#17145] Ractor-aware `Object#deep_freeze`
From:
ko1@...
Date:
2020-10-23 20:00:08 UTC
List:
ruby-core #100514
Issue #17145 has been updated by ko1 (Koichi Sasada).
Sorry I misunderstood this proposal.
`Ractor.make_shareable(obj)` proposal (#17274) satisfies the functionality proposed here.
(I thought `deep_freeze(skip_shareable: false)` was the proposal. sorry I skipped to read).
We discussed about the name "deep_freeze", and Matz said `deep_freeze` should be only for freezing, not related to Ractor. So classes/module should be frozen if `[C].deep_freeze`. This is why I proposed a `Object#deep_freeze(skip_shareable: true)` and `Ractor.make_shareable(obj)`.
Anyway maybe the functionality should be okay (calling `freeze` by `make_shareable` proposal).
So naming issue is reamained?
* `Object#deep_freeze` (matz doesn't like it)
* `Object#deep_freeze(skip_sharable: true)` (I don't know how Matz feel. And it is difficult to define Class/Module/...)
* `Ractor.make_shareable(obj)` (clear for me, but it is a bit long)
* `Ractor.shareable!(obj)` (shorter. is it clear?)
* `Object#shareable!` (is it acceptable?)
* ... other ideas?
----------------------------------------
Feature #17145: Ractor-aware `Object#deep_freeze`
https://bugs.ruby-lang.org/issues/17145#change-88137
* 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: #<Fire:0x00007ff151994748>"
```
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>