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=no 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 3AB0E1F87F for ; Thu, 22 Nov 2018 05:40:23 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 0B10E1211C7; Thu, 22 Nov 2018 14:40:21 +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 C7256120EA1 for ; Thu, 22 Nov 2018 14:40:18 +0900 (JST) Received: by filter0102p3iad2.sendgrid.net with SMTP id filter0102p3iad2-20662-5BF6413F-B 2018-11-22 05:40:15.281746483 +0000 UTC m=+553143.163377702 Received: from herokuapp.com (ec2-54-211-57-18.compute-1.amazonaws.com [54.211.57.18]) by ismtpd0017p1iad1.sendgrid.net (SG) with ESMTP id EMjTRMgRR7GbJOLwFqT42w for ; Thu, 22 Nov 2018 05:40:15.147 +0000 (UTC) Date: Thu, 22 Nov 2018 05:40:15 +0000 (UTC) From: shevegen@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65345 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15330 X-Redmine-Issue-Author: marcandre X-Redmine-Issue-Assignee: matz X-Redmine-Sender: shevegen 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS7G2un/c1lweK6sCR93Lt0H+EIBAOnwwST9Kn +x1znaNX68JA9nMEHvLsULz4M+IDK+wn4lExJk9Hr5yzdbvmWGRJQO1L2xhhW9uwJMqzQwDgzBgM2t DNLZoaaKRygzUkEFfYT5IdqzZX2wXc9ANQSjJbDxhNOMoEG/g65zZklGpw== X-ML-Name: ruby-core X-Mail-Count: 89948 Subject: [ruby-core:89948] [Ruby trunk Feature#15330] autoload_relative 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 #15330 has been updated by shevegen (Robert A. Heiler). I do not have much to add to autoload_relative as such, although I would like to mention that, similar to require_relative, the shorter variants are easier to write - e. g. "require 'path'" versus "require_relative 'path'"; similar to autoload versus autoload_require. However had, more importantly to the issue at hand, I think the functionality that autoload() offers should be retained. That does not necessarily mean that the name as such should remain (I am neutral about it; I use autoload myself but I don't mind either way, whether it is there or not), but the functionality can be useful. Sometimes in large projects, using a linear setup e. g. require one project after the other, can take quite some time to startup. This may normally not be a problem, but I found in one of my projects where I make use of a REPL, such as the user starting a shell, before typing commands, I prefer a fast startup time. I was experimenting with two approaches: one was via autoload, the other was a strange thought of using Thread.new to load addons that take time, and check whether the code was available or not via e. g. Object.const_defined? and something like that. This would allow the user to start typing stuff, but not all parts of the shell would work instantly; it may take up to 7 seconds or so before all commands would available from that shell. (If anyone is wondering why that takes so long, I literally have one admin-like shell interface that pretty much loads ALL the gems and .rb files that I may ever need; and I was mostly just experimenting anyway.) The autoload part of the code was actually quite simple; I sort of defined all autoloads that this shell would use in a single .rb file and not worry about it lateron. I think Hiroshi Shibata made some suggestion some time ago about extending require (or the require-family in ruby); I myself also wonder how to suggest some more flexible way of requiring files, including perhaps autoload-functionality there, rather than autoload() as such; or the ability to use "identifiers" that are mapped on a per-project basis to a .rb file, so that we can use something like a single :symbol to require files even from outside of a project, rather than rely on a hardcoded path to .rb files that may change - but I am going off-topic. I just wanted to mention this. So as summary, I think autoload-functionality should remain; as to whether the name autoload() should remain or not is, I think, secondary (to me at the least). I understand that your suggestion is to extend on the autoload-family with your suggestion :) - but I am really neutral about it either way, so I don't mind what happens there. (Actually, for my idea of another require way, I thought of identifiers via something like require_project 'rack|base' or require_project 'rack@base' or something like that, but I did not like my own API suggestion so I did let this slide; I still think it would be nice to have a way to require .rb files without having to hardcode paths to .rb files). ---------------------------------------- Feature #15330: autoload_relative https://bugs.ruby-lang.org/issues/15330#change-75040 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: 2.6 ---------------------------------------- I'd like to propose a way to autoload a constant using a relative path. It could look like: ``` autoload_relative :MyConst, 'models/my_const' ``` My proposal raises two questions: 1) what's the future of `autoload`? I believe that `autoload` has been there for years, it is used successfully and has no real alternative. I looked at a sample of 430 top gems (took the 500 top ranked according to Libraries.io, removed those that I failed to process). The number of those gems that appear to use `autoload` at least once is 94 of those (22%). The number of lines in the code where `autoload` is called can be quite big. The top 5 are: vagrant: 235 yard: 206 ffaker: 155 aws-sdk: 152 rdoc: 92 This is a minimum bound, as some gems might be using loops, my processing would only detect the one place in the code with `autoload`. 2) are many autoladed paths relative? My preliminary numbers indicate that of the 94 gems using autoload, at least 75 are autoloading some relative files. That's a lower bound, as my algorithm is pretty crude and will only count the simplest cases as being relative. An example of gem my algorithm does not detect is `yard`, because the author wrote a small method to map the relative paths to global paths (code here: https://github.com/lsegal/yard/blob/master/lib/yard/autoload.rb#L3 ) Of those where my processing detects the relative requires, a vast majority are relative. The average is that 94% of autoloaded files are relative and would benefit from `require_relative` In summary: I am convinced that `autoload` should remain in Ruby indefinitely. `autoload_relative` would actually be more useful than `autoload`. Even if the future of `autoload` remains uncertain, I would recommend adding `autoload_relative`; if it is ever decided to actually remove `autoload`, removing `autoload_relative` would not really add to the (huge) burden of gem maintainers. -- https://bugs.ruby-lang.org/