[#90399] [Ruby trunk Feature#14813] [PATCH] gc.c: make gc_enter+gc_exit pairs dtrace probes, too — ko1@...
Issue #14813 has been updated by ko1 (Koichi Sasada).
3 messages
2018/12/10
[#90417] [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD — naruse@...
Issue #15398 has been reported by naruse (Yui NARUSE).
4 messages
2018/12/11
[#90423] Re: [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD
— Eric Wong <normalperson@...>
2018/12/11
[email protected] wrote:
[#90519] Spoofing warnings for mail from bugs.ruby-lang.org — Charles Oliver Nutter <headius@...>
I'm getting a spoofing warning for emails sent from bugs.ruby-lang.org when
4 messages
2018/12/13
[#90522] Re: Spoofing warnings for mail from bugs.ruby-lang.org
— Eric Wong <normalperson@...>
2018/12/13
Charles Oliver Nutter <[email protected]> wrote:
[#90533] [Ruby trunk Feature#15413] unmarkable C stack (3rd stack) — normalperson@...
Issue #15413 has been reported by normalperson (Eric Wong).
3 messages
2018/12/14
[#90581] [Ruby trunk Bug#15424] Ruby 2.6.0rc1 & 2.6.0rc2 mutex exception — mat999@...
Issue #15424 has been reported by splitice (Mathew Heard).
3 messages
2018/12/17
[#90595] [Ruby trunk Bug#15430] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been reported by hsbt (Hiroshi SHIBATA).
3 messages
2018/12/18
[#90614] [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been updated by hsbt (Hiroshi SHIBATA).
4 messages
2018/12/19
[#90630] Re: [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI
— Eric Wong <normalperson@...>
2018/12/20
> It still exists. https://rubyci.org/logs/rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181218T230003Z.fail.html.gz
[#90820] Re: [ruby-cvs:73697] k0kubun:r66593 (trunk): accept_nonblock_spec.rb: skip spurious failure — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/12/30
[ruby-core:90420] [Ruby trunk Bug#14541] Class variables have broken semantics, let's fix them
From:
lamont@...
Date:
2018-12-11 18:24:51 UTC
List:
ruby-core #90420
Issue #14541 has been updated by lamont (Lamont Granquist).
Inheritance of @@class variables is precisely what makes them useful, since they're truly one single global value.
And in addition to what matz points out rubocop has the Cop::Style::ClassVars warning.
As someone who manages a 10 year old, 250,000 line long ruby codebase, please don't remove them or change the semantics. The class variables we have now in our project have often been around for 10 years and while in some purist sense they are all technical debt, they're not doing any harm -- forcing me to have a flag day to fix them all would be a large waste of my time (some of them have been fixed as they've been found to be problematic and/or the code in question simply got cleaned up as part of a larger refactoring pass).
----------------------------------------
Bug #14541: Class variables have broken semantics, let's fix them
https://bugs.ruby-lang.org/issues/14541#change-75575
* 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 `<main>'
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 `<main>'
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: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>