[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70246] [Ruby trunk - Feature #11415] [Open] autoload with a Proc
From:
matthew@...
Date:
2015-08-05 02:28:20 UTC
List:
ruby-core #70246
Issue #11415 has been reported by Matthew Draper.
----------------------------------------
Feature #11415: autoload with a Proc
https://bugs.ruby-lang.org/issues/11415
* Author: Matthew Draper
* Status: Open
* Priority: Normal
* Assignee:
----------------------------------------
`autoload` currently allows you to run arbitrary code when a constant is referenced, as long as that code is written to a file.
I propose extending `autoload` to also accept a Proc in place of the string filename.
Usage:
autoload :Foo, -> { ::Object.const_set :Foo, 42 }
autoload :Bar, -> { require "bar_1"; require "bar_2" }
autoload :Baz, -> { with_special_lock { require "baz" } }
No built-in concurrency protection is provided: if a second thread encounters a constant reference before the first one sets the constant, the second thread will also enter the Proc.
Under simple usage, the proc will still call require at some point -- then require's locking will take effect. A more advanced user can apply their own locking.
I believe this is sufficient to allow the Rails dependency loader to use autoload instead of const_missing, and fix the "nested constants" problem.
The implementation is quite small, and it doesn't seem to make the dangers of autoload any worse than they already are. Hopefully, it can provide an easier place for users to experiment in ways to save autoload by making it more generally safe.
*Alternatives*
For Rails's purposes, nested constants could also be solved by a `missing_constant` (or similar) macro:
module Foo; end
module Bar; end
Foo::Bar # => returns ::Bar
module Foo; missing_constant :Bar; end
module Bar
Foo::Bar # => invokes Foo.const_missing(:Bar)
More directly, instead of passing a Proc to autoload, a caller can write the code to a tempfile, and then specify that tempfile's path.
---Files--------------------------------
autoload-proc.patch (5.83 KB)
--
https://bugs.ruby-lang.org/