From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 48B0D1F453 for ; Sun, 10 Feb 2019 15:20:11 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id A0158114CCB; Mon, 11 Feb 2019 00:20:07 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id D9103114CC7 for ; Mon, 11 Feb 2019 00:20:04 +0900 (JST) Received: by filter0034p3las1.sendgrid.net with SMTP id filter0034p3las1-26498-5C604121-38 2019-02-10 15:20:01.973121284 +0000 UTC m=+418762.376059663 Received: from herokuapp.com (ec2-54-80-191-111.compute-1.amazonaws.com [54.80.191.111]) by ismtpd0030p1mdw1.sendgrid.net (SG) with ESMTP id N6wbRaBrRc-Wtt0WdWXh5Q for ; Sun, 10 Feb 2019 15:20:01.931 +0000 (UTC) Date: Sun, 10 Feb 2019 15:20:03 +0000 (UTC) From: Greg.mpls@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66957 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15592 X-Redmine-Issue-Author: akr X-Redmine-Sender: MSP-Greg X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS7HUy0dGKEt1m3SX35zDb+EWmeAPXN5yJLVgO mMhE2rSsF42C8z6PAYXfs4ke+6YgiA2K+1Pn9JkV/J9y0ff9SBoVbFOQz/XnessMP4QwWJIh6G49UU 7CufonVAqFT3FbU2AFAeCT2G7D6gXnuWTDzk8/ms/Oay+EWjO1qG5S030w== X-ML-Name: ruby-core X-Mail-Count: 91504 Subject: [ruby-core:91504] [Ruby trunk Feature#15592] mode where "autoload" behaves like an immediate "require" X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15592 has been updated by MSP-Greg (Greg L). I'm very in favor of some type of switching mechanism to allow 'autoload' to switch between immediate & lazy loading. I'll call it 'AorR', for 'autoload or require?'. I'm confused about the desired scope of this. Given previously: ```ruby # m.rb module M autoload :X, 'm/x' autoload :Y, 'm/y' end ``` Two possible options: 1. Adding an optional parameter to autoload to control whether it acts like a require statement. 2. Adding a mechanism to control AorR within a file/module. Regarding option 1: It seems like too fine grained a level of control. After all, one could just require specific files. Then again, see 'Off-Topic' Regarding option 2: I think the idea of being able to place all of the AorR switches in one place (affecting all autoload statements in the app) would be very helpful. One might also like them in separate places. Maybe something like a (global) array that contains the namespaces (stored as symbols or strings) where autoload statements switch to requires? I assume this would become much more complex if it needed to affect previously loaded files. Off Topic: The coupling between files and objects has been somewhat tight in many languages. Obviously, it's not necessarily a one-to-one relationship (example - the io/* std-lib's). But, one could state that a goal of a higher level language would be to abstract them. Hence, as an example, an application (or a gem) could totally change their file structure without breaking any applications that use it. ---------------------------------------- Feature #15592: mode where "autoload" behaves like an immediate "require" https://bugs.ruby-lang.org/issues/15592#change-76764 * Author: akr (Akira Tanaka) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- How about a feature to switch "autoload" behavior to "require" immediately. autoload is a feature for lazy loading. matz dislikes autoload as [Feature #5653]. I heard that he dislikes class (and other) definitions at arbitrary timing. I agree that eager loading is safer than lazy loading. However, lazy loading realize shorter loading time and it makes development cycle shorter. It is more important for larger applications as Eregon said in https://bugs.ruby-lang.org/issues/5653#note-39 . It is especially important when library loading causes I/O (code generation from DB schema). These two, safety of eager loading and easier development of lazy loading, conflicts. But if we can distinguish production mode and development mode, we can enjoy both benefits. So, I propose a feature to select autoload behavior from two modes: - autoload behaves as lazy loading as now in development mode - autoload behaves as eager loading (immediately invokes "require") in production mode. There are several idea to switch the mode: - $AUTOLOAD_MODE = :eager or :lazy - RubyVM.autoload_mode = :eager or :lazy - ObjectSpace.autoload_mode = :eager or lazy I'm not sure there is a good enough one in above list, though. -- https://bugs.ruby-lang.org/