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
-~----------~----~----~----~------~----~------~--~---

Reply via email to