From: eregontp@... Date: 2018-03-15T12:24:43+00:00 Subject: [ruby-core:86142] [Ruby trunk Bug#14541] Class variables have broken semantics, let's fix them Issue #14541 has been updated by Eregon (Benoit Daloze). matz (Yukihiro Matsumoto) wrote: > It's possible to make those warning replaced by exceptions. I am strongly positive about it. OK, at least that would remove the very confusing semantics of a class variable in a superclass removes class variables with the same name in subclasses. What exception class should be used? A RuntimeError? FWIW, I tried removing the class hierarchy lookup for class variables. Here is an incomplete patch, but it passes ruby/spec and almost test-all (a couple tests hang, I didn't have time to investigate those): https://github.com/ruby/ruby/compare/trunk...eregon:classvar_not_inherited CGI and Gem::TestCase seem to use class variables pretty much like global variables, so I replaced those with class-level instance variables. I think it would be worth to merge those changes, regardless of what happens to class variables, since it makes the logic much clearer. I hope I'll have time for it. ---------------------------------------- Bug #14541: Class variables have broken semantics, let's fix them https://bugs.ruby-lang.org/issues/14541#change-71022 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.6.0dev (2018-01-29 trunk 62091) [x86_64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Class variables have the weird semantics of being tied to the class hierarchy and being inherited between classes. I think this is counter-intuitive, dangerous and basically nobody expects this behavior. To illustrate that, we can break the tmpdir stdlib by defining a top-level class variable: $ ruby -rtmpdir -e '$SAFE=1; @@systmpdir=42; p Dir.mktmpdir {}' -e:1: warning: class variable access from toplevel Traceback (most recent call last): 3: from -e:1:in `
' 2: from /home/eregon/prefix/ruby-trunk/lib/ruby/2.6.0/tmpdir.rb:86:in `mktmpdir' 1: from /home/eregon/prefix/ruby-trunk/lib/ruby/2.6.0/tmpdir.rb:125:in `create' /home/eregon/prefix/ruby-trunk/lib/ruby/2.6.0/tmpdir.rb:125:in `join': no implicit conversion of Integer into String (TypeError) Or even simpler in RubyGems: $ ruby -e '@@all=42; p Gem.ruby_version' -e:1: warning: class variable access from toplevel Traceback (most recent call last): 3: from -e:1:in `
' 2: from /home/eregon/prefix/ruby-trunk/lib/ruby/2.6.0/rubygems.rb:984:in `ruby_version' 1: from /home/eregon/prefix/ruby-trunk/lib/ruby/2.6.0/rubygems/version.rb:199:in `new' /home/eregon/prefix/ruby-trunk/lib/ruby/2.6.0/rubygems/version.rb:199:in `[]': no implicit conversion of String into Integer (TypeError) So defining a class variable on Object removes class variables in all classes inheriting from Object. Maybe @@systmpdir is not so prone to conflict, but how about @@identifier, @@context, @@locales, @@sequence, @@all, etc which are class variables of the standard library? Moreover, class variables are extremely complex to implement correctly and very difficult to optimize due to the complex semantics. In fact, none of JRuby, TruffleRuby, Rubinius and MRuby implement the "setting a class var on Object removes class vars in subclasses". It seems all implementations but MRI print :foo twice here (instead of :foo :toplevel for MRI): ~~~ ruby class Foo @@cvar = :foo def self.read @@cvar end end p Foo.read @@cvar = :toplevel p Foo.read ~~~ Is there any library actually taking advantage that class variables are inherited between classes? I would guess not or very few. Therefore, I propose to give class variable intuitive semantics: no inheritance, they behave just like variables of that specific class, much like class-level instance variables (but separate for compatibility). Another option is to remove them completely, but that's likely too hard for compatibility. Thoughts? -- https://bugs.ruby-lang.org/ Unsubscribe: