From: "mame (Yusuke Endoh)" <mame@tsg.ne.jp>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:43755] [ruby-trunk - Feature #5653][Assigned] "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead)
Date: Wed, 28 Mar 2012 00:33:23 +0900 [thread overview]
Message-ID: <redmine.journal-25265.20120328003322@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-5653.20111121172400@ruby-lang.org
Issue #5653 has been updated by mame (Yusuke Endoh).
Status changed from Open to Assigned
Assignee set to nahi (Hiroshi Nakamura)
Hello, NaHi-san
Hiroshi Nakamura wrote:
> This ticket is for discussion about removing autoload from stdlib (or not)
It would be good to open tickets for each library that uses autoload.
And, what do you think about Stephen and Yehuda's opinion?
It looks reasonable to me.
Stephen Touset wrote:
> After discussion last night with Yehuda, we both agreed that this issue isn't resolved by #2740. Since const_missing is never called when Ruby resolves a constant like Foo::Bar to Object::Bar, it cannot be used as a replacement to autoload, which does trigger before the constant lookup is delegated to Object.
>
> This is a more common occurrence than you might think. Requiring any gem or outside library that defines a top-level constant named the same as a nested constant you've autoloaded (via const_missing) in your project will prevent that nested constant from ever being visible.
--
Yusuke Endoh <mame@tsg.ne.jp>
----------------------------------------
Feature #5653: "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead)
https://bugs.ruby-lang.org/issues/5653#change-25265
Author: matz (Yukihiro Matsumoto)
Status: Assigned
Priority: Normal
Assignee: nahi (Hiroshi Nakamura)
Category: lib
Target version: 2.0.0
Hi,
Today, I talked with NaHi about enhancing const_missing to enable
autoload-like feature with nested modules. But autoload itself has
fundamental flaw under multi-thread environment. I should have remove
autoload when I added threads to the language (threads came a few
months after autoload).
So I hereby declare the future deprecation of autoload. Ruby will
keep autoload for a while, since 2.0 should keep compatibility to 1.9.
But you don't expect it will survive further future, e.g. 3.0.
I strongly discourage the use of autoload in any standard libraries.
matz.
--
http://bugs.ruby-lang.org/
next prev parent reply other threads:[~2012-03-27 15:50 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-5653.20111121172400@ruby-lang.org>
2011-11-21 8:28 ` [ruby-core:41171] [ruby-trunk - Feature #5653] "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead) Hiroshi Nakamura
2011-11-21 19:51 ` [ruby-core:41179] " Aaron Patterson
2011-11-22 5:03 ` [ruby-core:41192] " Eric Hodel
2011-11-22 0:57 ` [ruby-core:41183] " jonathan rochkind
2011-11-22 1:25 ` [ruby-core:41184] " Yukihiro Matsumoto
2011-12-01 1:16 ` [ruby-core:41421] " Stephen Touset
2011-12-01 1:34 ` [ruby-core:41423] " Stephen Touset
2011-12-01 1:36 ` [ruby-core:41426] " Yehuda Katz
2011-12-01 14:14 ` [ruby-core:41432] " Stephen Touset
2012-03-27 15:33 ` mame (Yusuke Endoh) [this message]
2012-06-14 17:37 ` [ruby-core:45653] " trans (Thomas Sawyer)
2012-06-30 15:24 ` [ruby-core:45991] " nahi (Hiroshi Nakamura)
2012-06-30 16:35 ` [ruby-core:46000] " rosenfeld (Rodrigo Rosenfeld Rosas)
2012-06-30 22:23 ` [ruby-core:46023] " nahi (Hiroshi Nakamura)
2012-07-01 13:10 ` [ruby-core:46052] " rosenfeld (Rodrigo Rosenfeld Rosas)
2012-07-01 18:13 ` [ruby-core:46079] " mame (Yusuke Endoh)
2012-07-01 18:32 ` [ruby-core:46084] " trans (Thomas Sawyer)
2012-07-01 18:56 ` [ruby-core:46086] " funny_falcon (Yura Sokolov)
2012-07-03 13:53 ` [ruby-core:46142] " rosenfeld (Rodrigo Rosenfeld Rosas)
2012-11-23 23:36 ` [ruby-core:49910] " mame (Yusuke Endoh)
2013-02-12 13:38 ` [ruby-core:52154] " rosenfeld (Rodrigo Rosenfeld Rosas)
2013-02-17 6:17 ` [ruby-core:52353] " ko1 (Koichi Sasada)
2013-05-22 3:46 ` [ruby-core:55107] " reset (Jamie Winsor)
2013-06-24 8:49 ` [ruby-core:55629] " se8 (Sébastien Durand)
2013-08-31 9:17 ` [ruby-core:56929] " boris_stitnicky (Boris Stitnicky)
2014-01-30 6:16 ` [ruby-core:60263] " shibata.hiroshi
2015-04-07 12:40 ` [ruby-core:68780] [Ruby trunk " plribeiro3000
2019-01-21 17:57 ` [ruby-core:91213] [Ruby trunk Feature#5653] " rafaelmfranca
2019-01-23 10:19 ` [ruby-core:91224] " shyouhei
2019-01-23 10:55 ` [ruby-core:91227] " eregontp
2019-01-23 13:39 ` [ruby-core:91228] " fxn
2019-01-24 10:19 ` [ruby-core:91247] " fxn
2019-01-28 16:22 ` [ruby-core:91307] " rr.rosas
2019-01-28 18:38 ` [ruby-core:91309] " rafaelmfranca
2019-02-03 23:01 ` [ruby-core:91388] " Greg.mpls
2019-02-05 14:27 ` [ruby-core:91411] " rr.rosas
2019-02-07 6:20 ` [ruby-core:91450] " matz
2019-02-07 7:02 ` [ruby-core:91455] " akr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-25265.20120328003322@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).