Actually, if you want to use something like unshift, I'd suggest just refactoring Merb::BootLoader.before/after_app_loads so that it's
Merb::BootLoader.load_before(:app) or Merb::BootLoader.load_after(:helpers) or, if you want to make it so they don't have to write the 'require' code themselves: Merb::BootLoader.load_path_before(:app, "/lib", "**/*.rb") Merb::BootLoader.load_path_before(:app, :lib) # would take path/glob from load_paths or whatever else you want. Although this *may* be a solution in search of a problem, and I don't think it's a substitute for a proper default bootloading order (so I'm still pushing for Jack Dempsey's patch ;) ). But what do you think? liam On Fri, Nov 21, 2008 at 2:56 PM, Liam Morley <[EMAIL PROTECTED]> wrote: > What if you want to stick something in the middle of the loading order? > Seems like you'd have to call unshift a few times, and you'd have to be > aware of what else is in the bootloader. > > I think this is one of those cases where it's better to have a suitable > default. > > The docs seem to imply that lib is loaded before app, and the > implementation seems to imply that app is loaded before lib. So the bug is > either in the docs or the implementation, we've already agreed that one of > these needs to be changed. > > I think the "principle of least surprise" (always to be read as the > "principle which would least surprise *me*, not sure about the rest of > you") would dictate that :lib (which is nil by default) is loaded before > :app, as this is the way that it's done in rails, etc- this is how people > expect it to operate based on prior experience with other popular MVC-based > frameworks, this is what's implied by the documentation, and a few people > (who have asked this question on IRC) were surprised to find that this > wasn't the way it operated. > > Yep, you would have backwards-compatibility issues if anybody has stuff in > lib/ that depends on app/. And while that is possible, convention (at least, > that I'm aware of) seems to imply that it's *usually *the other way > around. > > I was trying to think of way to specify the bootloading order declaratively > without inviting potentially dangerous code, but I couldn't think of > anything at the moment, so I won't suggest it. But if you do decide that you > really want to move things to the front like unshift, I would choose a > different name, like "preload" or something, that doesn't imply the > underlying implementation. Method names that imply underlying implementation > may cause people to assume that it's actually implemented that way, and rely > on that (ie, somebody might try to call push_path twice expecting the path > to operate like a stack). "preload" might not be exactly what you're going > for (it might carry its own set of implications), but something along those > lines. > > liam > > > > On Fri, Nov 21, 2008 at 1:58 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote: > >> Here's the problem: >> What if you have stuff in lib/ that depends on stuff in your models. I >> think this needs to be something that is decided on a case-by-case basis. We >> can apply the patch, but I suspect it will have potentially back-compat >> breaking implications. What I really want is unshift_path, which would move >> the path to the front of the list. Again, does this satisfy people's >> concerns? >> >> Is the issue with unshift_path confusion? We can make it clear! >> >> -- Yehuda >> >> On Wed, Nov 19, 2008 at 5:12 PM, Erik Lagercrantz <[EMAIL PROTECTED]>wrote: >> >>> >>> I definitely agree with the decision not to enable magical autoloading >>> of lib, but I don't really understand how that turned into a decision >>> not to apply the patch in #1010. It seems reasonable to me that if lib >>> is added to the load paths at all (which it is), then that should be >>> done before adding the app directories, regardless of whether the >>> contents of either are autoloaded or not. >>> >>> It's not a very big issue because I can easily customize the load >>> paths by adding my own config/framework.rb file, but it would be nice >>> to have a better default order. The patch doesn't change anything but >>> the order, does it? Would there be any downsides to applying it? >>> >>> Erik >>> >>> On 17 Nov, 07:54, "Michael Klishin" <[EMAIL PROTECTED]> >>> wrote: >>> > 2008/11/17 Matt Aimonetti <[EMAIL PROTECTED]>: >>> > >>> > > Do I understand that we have an agreement and lib code shouldn't be >>> auto >>> > > loaded? >>> > >>> > Looks like like the agreement is to keep things the way they are and >>> > add some documentation. >>> > -- >>> > MK >>> >>> >> >> >> -- >> Yehuda Katz >> Developer | Engine Yard >> (ph) 718.877.1325 >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" 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/merb?hl=en -~----------~----~----~----~------~----~------~--~---
