> On Jan 1, 2016, at 10:31 AM, Xavier Noria <f...@hashref.com> wrote: > > 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 > > <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. >
Based on https://github.com/ruby/ruby/blob/v2_1_0/doc/syntax/refinements.rdoc <https://github.com/ruby/ruby/blob/v2_1_0/doc/syntax/refinements.rdoc> , there does not appear to be a way for a `require`d file to trigger `using` in the parent file: titleize_string.rb: module TitleizeString refine String do def titleize ... end end using TitleizeString # only active until end of titleize_string.rb! use_case.rb: require ‘titleize_string’ puts “foo”.titleize # => NoMethodError This also implies a “using ActiveSupport::BagORefinements” at the top of a *lot* of files in the typical application. :( On the performance front, IIRC part of the reason for the strong lexical scoping of refinements was performance concerns regarding the original dynamic implementation’s effects on method lookup caching. —Matt Jones > 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 rubyonrails-core+unsubscr...@googlegroups.com > <mailto:rubyonrails-core+unsubscr...@googlegroups.com>. > To post to this group, send email to rubyonrails-core@googlegroups.com > <mailto:rubyonrails-core@googlegroups.com>. > Visit this group at https://groups.google.com/group/rubyonrails-core > <https://groups.google.com/group/rubyonrails-core>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
