[#70977] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3 — arai@...
Issue #11473 has been updated by Shunichi Arai.
3 messages
2015/10/04
[#70982] limiting scope of magic comments like frozen_string_literal — Eric Wong <normalperson@...>
How about being able to limit the scope of magic comments like
4 messages
2015/10/05
[#71062] [Ruby trunk - Bug #10892] Deadlock in autoload — eregontp@...
Issue #10892 has been updated by Benoit Daloze.
4 messages
2015/10/12
[#71090] Re: [Ruby trunk - Bug #10892] Deadlock in autoload
— Eric Wong <normalperson@...>
2015/10/14
eregontp@gmail.com wrote:
[#71127] [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call — normalperson@...
Issue #11607 has been updated by Eric Wong.
3 messages
2015/10/20
[#71164] [Ruby trunk - Feature #11614] [Open] [RFC] use id_table for constant tables — normalperson@...
Issue #11614 has been reported by Eric Wong.
3 messages
2015/10/22
[#71211] [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call — naruse@...
Issue #11607 has been updated by Yui NARUSE.
6 messages
2015/10/27
[#71212] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Eric Wong <normalperson@...>
2015/10/27
Yes, user must check if the function is MT-safe. Probably fine
[#71246] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Aaron Patterson <tenderlove@...>
2015/10/28
On Tue, Oct 27, 2015 at 08:54:07AM +0000, Eric Wong wrote:
[#71254] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Eric Wong <normalperson@...>
2015/10/28
Aaron Patterson <tenderlove@ruby-lang.org> wrote:
[#71230] [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations — tenderlove@...
Issue #11625 has been updated by Aaron Patterson.
5 messages
2015/10/27
[#71236] Re: [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations
— Юрий Соколов <funny.falcon@...>
2015/10/28
What's about other hashsum algos? MD5, SHA2, etc
[#71242] Re: [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations
— Eric Wong <normalperson@...>
2015/10/28
Юрий Соколов <funny.falcon@gmail.com> wrote:
[#71239] [Ruby trunk - Bug #11384] multi-threaded autoload sometimes fails — shugo@...
Issue #11384 has been updated by Shugo Maeda.
4 messages
2015/10/28
[ruby-core:71055] [Ruby trunk - Feature #11550] Current behaviour of super(...) is dangerous in the presence of more than one included modules.
From:
ynnor@...
Date:
2015-10-12 10:47:51 UTC
List:
ruby-core #71055
Issue #11550 has been updated by Ronald Fischer.
Benoit Daloze wrote:
> Why not simply having `super` in M1 and M2 #initialize?
> All constructors should call `super`, unless they just inherit from Object/BasicObject.
First, M1 and M2 don't know where they are going to be mixed in, so they can not invoke `suuper` - they don't know what parameters are being passed.
Second, the class which mixes in M1 and M2 needs to initialize two modules, which is not possible with the current language.
----------------------------------------
Feature #11550: Current behaviour of super(...) is dangerous in the presence of more than one included modules.
https://bugs.ruby-lang.org/issues/11550#change-54424
* Author: Ronald Fischer
* Status: Open
* Priority: Normal
* Assignee:
----------------------------------------
Consider a class
~~~
class C <P
include M1
include M2
def initialize
....
end
end
~~~
If P, M1 and M2 all provide a initialize method, and C::initialize calls super(...), the first initialize module in the chain, which has a formal parameter list matching the actual parameters in the super(....) call, is executed. The other ones are not executed. The following article demonstrates a clever way, how C::initialize can call all initializers of the included modules and of the parent class:
[[http://stdout.koraktor.de/blog/2010/10/13/ruby-calling-super-constructors-from-multiple-included-modules/]]
This solution works, but is complicated, and the reason is that the basic design of Ruby, with respect of initializing the base class, is flawed, for the following reason:
If we define an 'initialize' method, we certainly assume that its execution is necessary for the correct behaviour of our class or module. Therefore, the designer of a class or module should at least have the possibility to REQUIRE that initialize will be called (by a derived class), and the designer of a class which inherits from a parent class or includes a module, should have an EASY way to call all the parent initializers.
Here a first draft of how the language could be changed to meet this criterium; it's perhaps not the best design, but it might help clarifying my point:
(1) A class (or module) may define either a method initialize or a method initialize_strict (but not both). If it has initialize_strict defined, and the class where the module is included, respectively the class which inherits it, does NOT invoke this initializer, an exception is thrown, UNLESS initialize_strict can be called without parameters. In the latter case, it is always executed (even if no 'super' call is present).
(2) A class method super_of is added to class Object, with the prototype super_of(klass,arg*), where klass is a symbol or String or instance of type Class or Module. The affect of invoking super_of(:Foo,x,y) is identical to invoking initialize(x,y) in the ancestor class Foo. If Foo is neither a direct ancestor nor an included module, an exception is thrown.
--
https://bugs.ruby-lang.org/