I think I'm late to the party, but I was the one who logged the bug with the current set up <http://merb.lighthouseapp.com/projects/7433- merb/tickets/1010>, I thought I might weigh in.
The way things are right now is that, by doing nothing, lib is not loaded at all, but if you choose to *explicitly* load lib into your path by using push_path, it's loaded after the rest of your code, hence your code can't reference it unless you manually require it. I can't really see how this is the best approach. Because push_path takes a path argument (the default is lib/**/*.rb but you can set it differently), you can set different rules for how you want to import your code. You could, for example, autoload lib/ *.rb, and anything in a subdirectory would not be loaded. There are a lot of options here, and none of them are magic due to the fact that you need to explicitly invoke push_path. I think everybody wants less magic, which is why I'm thrilled about this explicit invocation. But push_path that my app can't make use of seems impotent to me. I'm all for including :lib before the code in :app, but continuing to have the default :lib path be nil, and avoid autoloading. (I'm not sure if that's what you guys were suggesting- my suggestion is not pro-autoloading, but nor is it pro- status quo.) Liam On Nov 17, 1:47 am, "Matt Aimonetti" <[EMAIL PROTECTED]> wrote: > Do I understand that we have an agreement and lib code shouldn't be auto > loaded? > (I'm sorry I didn't read every single msg in the thread) > > -Matt > > On Mon, Nov 17, 2008 at 1:43 AM, Michael Klishin < > > [EMAIL PROTECTED]> wrote: > > > 2008/11/17 Julian Leviston <[EMAIL PROTECTED]>: > > > > I reckon put the option in config. > > > Possible? > > > It is sure possible technically but if you ask me right now what is > > the ugliest piece of code in merb core that > > I hate, I'd say all the > > dependencies-to-framework-layout-to-boot-sequence parts. Don't get me > > wrong, they do not > > require you sitting for *hours* to understand and way better thought > > out that some other dependencies code that I've seen. > > But it's very tricky thing to modify, and it struggles from what I > > call "Dell vs. Apple problem": trying to support a lot of 3rd party > > code does make things complex, and bundling everything in a single > > monolithic package would make certain pieces of > > the framework much simpler (but it's never gonna happen to merb). > > > I personally would drop almost any feature just to not complicate it > > further. If we can explain people how to approach this autoloading > > behavior, > > it shouldn't be much of a problem. > > -- > > MK --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
