[ruby-core:109003] [Ruby master Feature#18841] Proposal: autoload_relative

[ruby-core:109003] [Ruby master Feature#18841] Proposal: autoload_relative

[fxn (Xavier Noria)]

Issue #18841 has been reported by fxn (Xavier Noria).

----------------------------------------
Feature #18841: Proposal: autoload_relative
https://bugs.ruby-lang.org/issues/18841

* Author: fxn (Xavier Noria)
* Status: Open
* Priority: Normal
----------------------------------------
In my experience, autoloads often reflect an existing hierarchical structure.

If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_record.rb). (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_support/dependencies/autoload.rb)).

I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too.



-- 
https://bugs.ruby-lang.org/

[ruby-core:109004] [Ruby master Feature#18841] Proposal: autoload_relative

[ioquatix (Samuel Williams)]

Issue #18841 has been updated by ioquatix (Samuel Williams).


Yes, great idea, and I can confirm I've run into issues with autoload loading the wrong files if you combine `autoload` with `require_relative`.

Also, since this does not exist yet, we can be more strict on how this works, as in `autoload_relative` can raise an exception if the constant is not defined correctly.

----------------------------------------
Feature #18841: Proposal: autoload_relative
https://bugs.ruby-lang.org/issues/18841#change-98114

* Author: fxn (Xavier Noria)
* Status: Open
* Priority: Normal
----------------------------------------
In my experience, autoloads often reflect an existing hierarchical structure.

If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_record.rb). (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_support/dependencies/autoload.rb)).

I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too.



-- 
https://bugs.ruby-lang.org/

[ruby-core:109005] [Ruby master Feature#18841] Proposal: autoload_relative

[marcandre (Marc-Andre Lafortune)]

Issue #18841 has been updated by marcandre (Marc-Andre Lafortune).


Note that this is a duplicate of https://bugs.ruby-lang.org/issues/15330, which includes some real world usage stats.

Making it strict seems like a good idea too.

----------------------------------------
Feature #18841: Proposal: autoload_relative
https://bugs.ruby-lang.org/issues/18841#change-98115

* Author: fxn (Xavier Noria)
* Status: Open
* Priority: Normal
----------------------------------------
In my experience, autoloads often reflect an existing hierarchical structure.

If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_record.rb). (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_support/dependencies/autoload.rb)).

I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too.



-- 
https://bugs.ruby-lang.org/

[ruby-core:109006] [Ruby master Feature#18841] Proposal: autoload_relative

[fxn (Xavier Noria)]

Issue #18841 has been updated by fxn (Xavier Noria).


Oh, I should have searched before! Can't close this one myself.

----------------------------------------
Feature #18841: Proposal: autoload_relative
https://bugs.ruby-lang.org/issues/18841#change-98116

* Author: fxn (Xavier Noria)
* Status: Open
* Priority: Normal
----------------------------------------
In my experience, autoloads often reflect an existing hierarchical structure.

If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_record.rb). (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_support/dependencies/autoload.rb)).

I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too.



-- 
https://bugs.ruby-lang.org/

[ruby-core:109008] [Ruby master Feature#18841] Proposal: autoload_relative

[ioquatix (Samuel Williams)]

Issue #18841 has been updated by ioquatix (Samuel Williams).


Great minds think alike! Thanks @marcandre.

@fxn I think the next step is to make a PR and then get Matz to review it.

----------------------------------------
Feature #18841: Proposal: autoload_relative
https://bugs.ruby-lang.org/issues/18841#change-98117

* Author: fxn (Xavier Noria)
* Status: Open
* Priority: Normal
----------------------------------------
In my experience, autoloads often reflect an existing hierarchical structure.

If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_record.rb). (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_support/dependencies/autoload.rb)).

I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too.



-- 
https://bugs.ruby-lang.org/

[ruby-core:112467] [Ruby master Feature#18841] Proposal: autoload_relative

[rubyFeedback (robert heiler) via ruby-core]

Issue #18841 has been updated by rubyFeedback (robert heiler).


I am not sure we should add more methods from within that
family (autoload-family). Personally I would even remove
require_relative, but I guess too much code depends on it
nowadays.

----------------------------------------
Feature #18841: Proposal: autoload_relative
https://bugs.ruby-lang.org/issues/18841#change-101912

* Author: fxn (Xavier Noria)
* Status: Open
* Priority: Normal
----------------------------------------
In my experience, autoloads often reflect an existing hierarchical structure.

If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_record.rb). (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_support/dependencies/autoload.rb)).

I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:124773] [Ruby Feature#18841] Proposal: autoload_relative

[ioquatix (Samuel Williams) via ruby-core]

Issue #18841 has been updated by ioquatix (Samuel Williams).

Status changed from Open to Closed

Closing in favour of https://bugs.ruby-lang.org/issues/15330

----------------------------------------
Feature #18841: Proposal: autoload_relative
https://bugs.ruby-lang.org/issues/18841#change-116382

* Author: fxn (Xavier Noria)
* Status: Closed
----------------------------------------
In my experience, autoloads often reflect an existing hierarchical structure.

If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_record.rb). (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_support/dependencies/autoload.rb)).

I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too.



-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/