I am only explaining why autoload and concern have no explicit requires in that file. That was a tangential question you did not directly related to the exception.
Sent from my iPhone On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas <[email protected]> wrote: > I don't understand what you mean. In my unit tests involving ParseFormatUtils > for instance Rails is never loaded and my application doesn't even use > ActiveRecord. > > But my tests weren't complaining anyway because they don't autoload > ActionView/Helpers. > > Also, even if I explicitly required as/rails it wouldn't fix the situation > for my case. > > This is what's happening in a simplified way: > > > ./test.rb: > autoload :A, 'a' > require 'a/b' > > ./lib/a.rb: > module A > autoload :B, 'a/b' > include B > end > > ./lib/a/b.rb: > module A > module B > end > end > > ruby -I lib test.rb > > > This is enough to create the circular dependency error. Maybe this is one of > the reasons why Matz wants to remove autoload from Ruby... > > Sorry but I don't have any suggestions right now that would make require > 'a/b' work if 'a' is set to be autoloaded and 'a' requires 'b' which depends > on 'a'... > > Unless we create some 'action_view/helpers/all.rb' file. Would that be > acceptable? > > Best, > Rodrigo. > > Em 08-02-2013 15:26, Xavier Noria escreveu: >> >> No, no, as/rails.rb is already required by the entry point >> of every component (except AS). That is a given in the >> context of a Rails application, and >> >> gem 'active_record' >> >> does that if standalone. >> >> Sent from my iPhone >> >> On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas <[email protected]> wrote: >> >>> Em 08-02-2013 15:00, Xavier Noria escreveu: >>>> >>>> Some very common files are loaded at the entry point of every component, >>>> to avoid repeating their require again and again: >>>> >>>> >>>> https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb >>> >>> But shouldn't helpers.rb require 'active_support/rails' then instead of >>> just 'active_support/benchmarkable'? >>> >>> Otherwise it should be documented that we're not supposed to require >>> specific parts of some libraries included in Rails... That way I'd know >>> (although surprised) that I'm not supposed to require >>> 'action_view/helpers/number_helper' but simply 'action_view/helpers' (or >>> just 'action_view'?) >>> >>>> >>>> As for the autoload + include, I don't really know, maybe it is a fancy >>>> way to avoid writing a file path. Seems unnecessary to me at first glance. >>>> Maybe someone else from the team has a better justification? >>>> >>>> Sent from my iPhone >>>> >>>> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas <[email protected]> >>>> wrote: >>>> >>>>> Em 08-02-2013 13:03, Xavier Noria escreveu: >>>>>> >>>>>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> Em 08-02-2013 12:06, Xavier Noria escreveu: >>>>>>> >>>>>>>> Seems unrelated to dependencies.rb, most likely a missing require >>>>>>>> somewhere within Rails. >>>>>>>> >>>>>>>> It can be the case that it does not show up in production because of >>>>>>>> eager >>>>>>>> loading. >>>>>>> Any ideas why helpers.rb is loaded when you write code like below? >>>>>>> >>>>>>> module ActionView >>>>>>> module Helpers >>>>>>> module NumberHelper >>>>>>> >>>>>>> Is this normal MRI behavior or is this caused by dependencies.rb? >>>>>> Ruby on Rails itself does not use dependencies.rb to load its code. It >>>>>> is a regular Ruby library that uses requires and Kernel#autoload with >>>>>> some added sugar. AS::Dependencies only covers application constant >>>>>> autoloading. >>>>>> >>>>>> The thing goes like this: When an application boots in any environment >>>>>> action_view.rb is loaded. When that file is executed an autoload for >>>>>> :Helpers is configured under ActionView. In a default setup, >>>>>> helpers.rb is not yet loaded. That is, if you run >>>>>> >>>>>> rails runner 1 >>>>>> >>>>>> helpers.rb is not loaded (at least in 3-2-stable, not that we are >>>>>> explaining any contract, only load order execution to follow what >>>>>> happens in your exception). >>>>>> >>>>>> But if you force the evaluation of the constant as in your example above: >>>>>> >>>>>> module ActionView >>>>>> module Helpers >>>>>> ... >>>>>> end >>>>>> end >>>>>> >>>>>> that autoload is triggered because the interpreter checks whether >>>>>> "Helpers" is a constant defined in the module object stored in >>>>>> ActionView. Therefore, helpers.rb is interpreted and sets in turn an >>>>>> autoload for NumberHelper below AV::Helpers. >>>>>> >>>>>> So, module Helpers in that snippet *reopens* a module object defined >>>>>> via the autoload, rather than creating the module object. The >>>>>> execution follows and the same happens with the "NumberHelper" >>>>>> constant down below. The interpreter checks whether it belongs to the >>>>>> module object stored in AV::Helpers. Since it is unknown and there is >>>>>> an autoload for it it gets triggered, and loads... well the very >>>>>> number_helper.rb whose execution we were in the middle of (not sure >>>>>> this sentence is valid English :). >>>>>> >>>>>> I suspect there is a circularity here that is showing up that way. >>>>>> >>>>>> Would need to dig deeper to fully explain how this ends up in an >>>>>> exception, maybe I'll do it tonight, but in the meantime here's some >>>>>> context in case it helps. >>>>> >>>>> It makes total sense. What doesn't make sense is the source of helpers.rb >>>>> to me: >>>>> >>>>> https://github.com/rails/rails/blob/master/actionpack/lib/action_view/helpers.rb >>>>> >>>>> First it should explicitly require (or require_dependency) >>>>> 'active_support/autoload' and 'active_support/concern', right? >>>>> >>>>> But then, why using autoload if you're just including all modules next? > > -- > 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 http://groups.google.com/group/rubyonrails-core?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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 http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
