On Nov 27, 2007, at 2:15 PM, James Adam wrote:
> > On Nov 27, 2007 8:55 PM, Chad Woolley <[EMAIL PROTECTED]> wrote: >> On 11/27/07, Michael Koziarski <[EMAIL PROTECTED]> wrote: >>> It seems counter intuitive that the loading and init-running >>> happen in >>> the opposite order. > > Unless I'm mistaken, this isn't the case. > > I'm not sure that everyone quite has the correct understanding of > what's going on when plugins are loaded. As Frederick says, the > init.rb files are evaluated in the default (A-Z) order. This is one of > the things that happens when a plugin is "loaded". > > The other thing which happens, is that the plugin's lib directory is > added to the $LOAD_PATH, under the application's lib directory (so > that the app can still override anything). But, as each plugin is > loaded, it's lib directory is "pushed" into this position, forcing the > other plugin lib directories to move below it. So with plugins A, B > and C we get > > Plugin A loading - $LOAD_PATH = [/lib, vendor/plugins/plugin_a/lib] > (approximately speaking, of course) > > Plugin B loading - $LOAD_PATH = [/lib, vendor/plugins/plugin_b/lib, > vendor/plugins/plugin_a/lib] > > Plugin C loading - $LOAD_PATH = [/lib, vendor/plugins/plugin_c/lib, > vendor/plugins/plugin_b/lib, vendor/plugins/plugin_a/lib] > > So the plugins ARE loaded in the order you expect, and the load paths > ARE added in the same order, it's just that they are treating that > particular part of the $LOAD_PATH like a stack - pushing each > subsequent plugin lib dir on top of the other plugins. > > Chad Wooley wrote: >> Right - but I'm asking what the default order should be if >> config.plugins is not specified. It seems like it should be >> alphabetical, but it's actually reverse alphabetical. > > Hopefully it's now clear why the current implementation results in > paths in the $LOAD_PATH that appear to be the reverse of the order in > which the plugins are loaded (or the order in config.plugins). > However, the fact that the orders are different doesn't mean that > anything is broken. The order in which the plugins appear in the > $LOAD_PATH is deliberately the reversed order in which they are > loaded. > > I'll explain why this is the case, and then in light of these reasons, > I think it would be useful to talk about *why* you feel this order > ought to be alphabetical. > > I believe that the original thinking was that plugins loaded "later" > would have a higher precedence. To have the plugins appear in the > $LOAD_PATH "alphabetically" would simply require some tuning of the > line which determines which index in the existing $LOAD_PATH that we > currently want to insert at. > > So the question really is, is this the behaviour that we want? The behavior as you describe it is what I would expect, but this is not quite what's currently implemented. Currently, the $LOAD_PATH is initialized in reverse alpha order (by set_load_path), then all plugins are initialized, in alpha order (by load_plugins), so all plugins have the same $LOAD_PATH. This can create some interesting situations where a plugin A sees only the code of plugin B (if B defines the same classes) when A is initializing. In fact, just last week, this exact behavior was happening between rspec and rspec_on_rails (now fixed). This would not happen if the implementation was using the behavior you describe. This would also be closer to gems loading behavior. That said, I'm not sure that's something you'd want to change as close to 2.0, especially since there are ways to write your plugin to ensure it loads its code, and not one from some other plugin. Cheers, Pascal. -- http://blog.nanorails.com > Should > the plugin which was loaded first have precedence to others when it > comes to requiring files? Or should it be, as it currently is (and as > you'd expect if you were loading any ruby source file over another > one) that plugins loaded last take precedence? > > -- > * J * > ~ > > > --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
