[#105450] [Ruby master Feature#18228] Add a `timeout` option to `IO.copy_stream` — "byroot (Jean Boussier)" <noreply@...>
Issue #18228 has been reported by byroot (Jean Boussier).
11 messages
2021/09/27
[ruby-core:105384] [Ruby master Feature#18035] Introduce general model/semantic for immutable by default.
From:
"tenderlovemaking (Aaron Patterson)" <noreply@...>
Date:
2021-09-22 22:07:07 UTC
List:
ruby-core #105384
Issue #18035 has been updated by tenderlovemaking (Aaron Patterson).
jeremyevans0 (Jeremy Evans) wrote in #note-13:
> tenderlovemaking (Aaron Patterson) wrote in #note-12:
> > jeremyevans0 (Jeremy Evans) wrote in #note-11:
> > > @maciej.mensfeld alluded to this already, but one thing to consider is that no object in Ruby is truly immutable unless all entries in `object.singleton_class.ancestors` are also frozen/immutable.
> >
> > Are they not? It seems like for Arrays they are (I haven't checked other types), so maybe there's some precedent:
> >
> > ```ruby
> > x = [1, 2, 3].freeze
> >
> > Mod = Module.new { def foo; end }
> >
> > begin
> > x.extend(Mod)
> > rescue FrozenError
> > puts "can't extend"
> > end
> >
> > begin
> > def x.foo; end
> > rescue FrozenError
> > puts "can't def"
> > end
> >
> > begin
> > y = x.singleton_class
> > def y.foo; end
> > rescue FrozenError
> > puts "can't def singleton"
> > end
> > ```
>
> Apologies for not being more clear. Freezing an object freezes the object's singleton class. However, it doesn't freeze the other ancestors in `singleton_class.ancestors`:
>
> ```ruby
> c = Class.new(Array)
> a = c.new
> a << 1
> a.first # => 1
> c.define_method(:first){0}
> a.first # => 0
> ```
>
> As this shows, an instance of a class is not immutable unless its class and all other ancestors of the singleton class are immutable.
Ah right. I think your example is missing a `freeze`, but I get it. If freezing an instance were to freeze all ancestors of the singleton, wouldn't that extend to `Object` / `BasicObject`? I feel like we'd have to stop freezing *somewhere* because it would be pretty surprising if you can't define a new class or something because someone did `[].freeze`. Simple statements like `FOO = [1].freeze` wouldn't work (as Object would get frozen before we could set the constant).
Maybe we could figure out a cheap way to copy things so that a mutation to the `Class.new` from your example wouldn't impact the instance `a`.
But regardless it seems like gradual introduction would be less surprising. IOW maybe the goal would be to make *all* references immutable, but that really isn't practical. Instead expand the frozen horizon as much as we can without breaking existing code?
----------------------------------------
Feature #18035: Introduce general model/semantic for immutable by default.
https://bugs.ruby-lang.org/issues/18035#change-93798
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
----------------------------------------
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 also 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>