On Nov 28, 2007 6:55 AM, James Adam <[EMAIL PROTECTED]> wrote: > It's interesting, given that the reason it was decided to add all load > paths before loading plugins was exactly to remove dependency > problems! (see > http://groups.google.com/group/rubyonrails-core/browse_frm/thread/7615e2ac0fa019d) > > I sympathise with your issue, but I'm not convinced this is a > regression. It sounds like rspec_on_rails contained a file something > like rspec_on_rails/lib/spec/matchers/have.rb, which was intended to > add behaviour to the corresponding file in the rspec plugin; but > making this rely on the order of the load path is never going to be an > optimal solution. If one plugin really needs to modify code provided > by another one, shouldn't it do this by either: > > * mixing in the new functionality via a module, or > * reopening the class manually, but *not* in a file which has the same > path as the file it is going to affect. > > In other words, and in general Ruby as well as Rails, if we ever have > files which have the same "relative" path (such as > spec/matchers/have.rb), it's always going to be difficult to guarantee > that one will be loaded over the other. It seems like the best way to > solve this is to simply avoid it.
Thanks for the responses, James. Those are great points, and that thread explains a lot. I'm totally in favor of gems-as-plugins. I think this is a good direction. -- Chad --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
