1.) Autloading is for constants not for anything else and it's
preferable you use autoload_once_paths instead of autoload_paths (at
least from my experience, others may differ on opinion and I don't
have any evidence to back up my claims other than what the name
implies and threading and what not.)
2.) Do not class_eval directly onto String, that's bad business,
monkey patching that way is a dirty dirty game and to most it's an
eternal sin... make your own module and do `String.send(:include,
MyModule)` because at least then there is a clear path back to where
it comes from, in your case nobody has any damn idea where the code
comes from therefore they have no real idea how to path it out at all.
__OPINION__
Normally what I do is one method per file patching and one include
file per patch w/ a generic all called patches.rb in the root of lib
that will load all the patches at once, but the former allows people
who take my code to pull specific code without having to dig, I am a
big fan of easy to follow code and code that is designed to be
decoupled (meaning my patches should not rely on each other and I
should be able to include a single and only a single patch if that's
what I want.) This means that I would do:
lib/my_app/core_ext/string/to_squawk.rb < The Patch.
lib/patches/stdlib/string/to_squawk.rb < The file that Patches String.
Here is an example: https://gist.github.com/5984753b60573f416820
__OPINION__
Now, most probably won't like the way I work with my patches some
people love to patch up STDLib like it's their day job and sole job
description so if you don't then what you need to do is just require
the file (lib is included in your load path by default in Rails) and
the patch will work but I think you should still fix that whole dirty
dirty way of patching in your method.
autoload_paths is the set of paths that can be autoloaded - they won’t actually be loaded on startup in development mode (although they would be in production).
The example in the doc is written from the point of view of writing the extension as part of a gem, in wich case lib/yaffle gets loaded for you by bundler. You seem to be adding this straight to your app, so you don’t get this behaviour. The simplest thing is probably to add an initializer that requires yoodle.rb for you
1.) Autloading is for constants not for anything else and it’s
preferable you use autoload_once_paths instead of autoload_paths (at
least from my experience, others may differ on opinion and I don’t
have any evidence to back up my claims other than what the name
implies and threading and what not.)
The difference between autoload_paths and autoload_once_paths is that in the development the former can be reloaded between requests whereas the latter will not. Which one is prefererable depends on what you’re doing, although of course the reloading behaviour is handy if those files are under active development. That doesn’t really work when the purpose of the file is to patch a core class that can’t itself be reloaded
