Not sure if I understand what the final proposition is here. #1010 is currently marked as waiting to be merged, would that be changed to nofix?
So an implementation of unshift_path would first remove the path from the dictionary and then unshift it to the beginning? Technically I imagine that would have the desired effect, although I imagine I'd be afraid to call something like that if I didn't have an understanding of what's going on under the hood- I'd feel like I'm mucking with the bootloading process, and "there be dragons". I understand maybe that's what we're going for, to make people feel cautious about playing with these sorts of things, but I'm also not for public API methods that let me feel like I'm mucking about, so I'm not sure if I like it. Personally I like Jack Dempsey's patch, but anything would work for me really, as long as the docs help to make the API intuitive. Still not sure if I understand the argument against Jack Dempsey's patch in #1010 (or am I misunderstanding your argument?)- it's not a patch that provides any magic, as push_path still needs to be explitly called. I expect that if somebody goes through the trouble of calling push_path :lib, it's because they want to have /lib available to the classes in their app. If we have a philosophical disagreement, then I'll back down immediately, I just want to make sure we're on the same page. If Jack Dempsey's patch *is*merged, then we're probably just having a misunderstanding, and I'm fine. liam On Wed, Nov 19, 2008 at 12:28 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote: > I previously proposed unshift_path. Does that work for you? > -- Yehuda > > On Tue, Nov 18, 2008 at 3:08 PM, Liam Morley <[EMAIL PROTECTED]> wrote: > >> >> 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<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 >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
