[#104481] [Ruby master Feature#18020] Introduce `IO::Buffer` for fiber scheduler. — samuel@...

Issue #18020 has been reported by ioquatix (Samuel Williams).

31 messages 2021/07/03

[#104492] [Ruby master Bug#18022] Spec errors for rbconfig/unicode_[emoji_]version_spec: Using Ruby 2.7 even when on Ruby 3.1 — duerst@...

Issue #18022 has been reported by duerst (Martin Dst).

8 messages 2021/07/04

[#104552] [Ruby master Feature#18033] Time.new to parse a string — nobu@...

Issue #18033 has been reported by nobu (Nobuyoshi Nakada).

26 messages 2021/07/09

[#104560] [Ruby master Bug#18035] Introduce general module for immutable by default. — samuel@...

Issue #18035 has been reported by ioquatix (Samuel Williams).

41 messages 2021/07/09

[#104629] [Ruby master Misc#18039] DevelopersMeeting20210819Japan — mame@...

Issue #18039 has been reported by mame (Yusuke Endoh).

11 messages 2021/07/16

[#104643] [Ruby master Bug#18040] Why should `foo(1 if true)` be an error? — bughit.github@...

Issue #18040 has been reported by bughit (bug hit).

10 messages 2021/07/19

[#104665] [Ruby master Feature#18042] YARV code optimization — motoroller95@...

Issue #18042 has been reported by motoroller (Iskandar Gohar).

11 messages 2021/07/23

[#104692] [Ruby master Bug#18048] Thread#join can break with fiber scheduler unblock fails or blocks. — samuel@...

Issue #18048 has been reported by ioquatix (Samuel Williams).

10 messages 2021/07/27

[#104723] [Ruby master Bug#18054] No rule to make target 'thread_fd_close.c', needed by 'thread_fd_close.o' — duerst@...

Issue #18054 has been reported by duerst (Martin Dst).

8 messages 2021/07/29

[ruby-core:104563] [Ruby master Bug#18035] Introduce general model/semantic for immutable by default.

From: duerst@...
Date: 2021-07-09 08:48:19 UTC
List: ruby-core #104563
Issue #18035 has been updated by duerst (Martin Dst).


This is mostly just a generic comment that may not be very helpful, but I can only say that I fully agree. Even before talking about parallel stuff (thread/fiber), knowing some object is frozen can be of help when optimizing.

One thing that might be of interest is that in a method chain, a lot of the intermediate objects (e.g. arrays, hashes) may be taken to be immutable because they are just passed to the next method in the chain and never used otherwise (but in this case, it's just the top object that's immutable, not necessarily the components, which may be passed along the chain).

----------------------------------------
Bug #18035: Introduce general model/semantic for immutable by default.
https://bugs.ruby-lang.org/issues/18035#change-92843

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby.

I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc.

I don't have any particular preference but:

- We should establish consistent patterns where possible, e.g.
  - Objects created by `new` are mutable.
  - Objects created by literal are immutable.

We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method?

Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems.

I als propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g.


```ruby
module Immutable
  def new(...)
    super.freeze
  end
end

class MyImmutableObject
  extend Immutable

  def initialize(x)
    @x = x
  end
  
  def freeze
    return self if frozen?
    
    @x.freeze
    
    super
  end
end

o = MyImmutableObject.new([1, 2, 3])
puts o.frozen?
```

Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient.

I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals.



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

In This Thread