Rails core - Jan 2010 - [PATCH] Rails 3.0.pre: Initializers do not always bind in the proper order

All,

I spent the past week updating the Devise auth engine to work with
Rails 3.  A huge part of that effort was reworking the way it
initializes and hooks into the system.  Along the way I noticed
that :before and :after conditions on initializers didn''t always cause
them to run when I thought they would.  I added some tests to the
initializable_test suite that illustrate the case.

The issue occurs when an initializer specifies a :before or :after
dependency that refers to another initializer that has not been loaded
yet.

I have also created a patch which leverages the Ruby stdlib''s tsort
module to do a full topological sort against the dependency list.  One
side effect of this is that multiple dependencies are trivially
implemented (although this patch merely resolves the current issue and
does not add that feature).

Another side effect of dependency resolution is that initializers are
not always guaranteed to run in the order they are declared.    (The
proposed implementation attempts to do this as often as possible, but
in some cases it would cause a cycle in the graph.)  I have attempted
to clarify this situation in the test code.

I am hoping this interests someone enough to review.  See the ticket
for more details.

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3788-rails-30pre-initializers-do-not-always-bind-in-the-proper-order#ticket-3788-3

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.