Let me give you some context and some initial thoughts.
*Context* In general, Rails makes extensive use of class reopening. For some time loading AS was all or nothing, but some years ago there was an effort to separate monkey patches in units to be able to cherry-pick them. This had a few implications: 1. Users of stand-alone AS have three levels of granularity to import stuff, from the most specific (I only want #blank? <https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/object/blank.rb>), to entity groups (I want all extensions to String <https://github.com/rails/rails/tree/master/activesupport/lib/active_support/core_ext/string>), to all AS core extensions <https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext.rb>. This organization is explained in the AS core extensions guide <http://guides.rubyonrails.org/active_support_core_extensions.html#stand-alone-active-support> . Thanks to this, merely depending on AS no longer modifies core classes. For starters, loading active_support.rb <https://github.com/rails/rails/blob/f263e250fe1656339043cf51a2075b9c97abfcce/activesupport/lib/active_support.rb> monkey patches nothing. You can depend on the library and cherry-pick just what you need, which is very lightweight. Of course, if the extension needs another one internally, it must be loaded. But generally speaking, that is kept as strict as possible. 2. Rails is a key client of AS. Being useful to Rails itself is the main criteria of inclusion of something in the core extensions. And each file in the Rails code base is responsible for cherry-picking exactly what it needs. Well, with some exceptions time proved to be worthwhile, the extensions in https://github.com/rails/rails/blob/master/activesupport /lib/active_support/rails.rb are imported by all Rails components other than AS itself for project convenience. 3. Ruby on Rails applications have the ability to say "load only what Rails itself needs, instead of all core extensions". You can express that with config.active_support.bare = true, though I think I have never seen it used. *Initial Thoughts* In principle, as a first step I would focus on Active Support stand-alone. And in a way that makes the current contract work transparently. Requiring the files you can require today should work exactly as it does today from the point of view of client code (mod ancestor chains maybe, ancestor chains are not public contract, they can be changed). In particular, the test suite of Rails should pass as is. This work would be organized in the file system in a structured and predictable way, perhaps similar to the current organization. Then a second step could be to refactor Rails itself. As I imagine it, this refactor would generally consist of changing every require with a corresponding using, modulus a ton of details probably :). We would need to see how the patch actually looks like. Don't know if there is any potential impact on performance, this should be also taken into account. If you'd like to explore this, you can count on me for support for certain. Xavier -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
