Thanks Jordon for your comments .. I appreciate your feedback just to mention that all this stuff is from Rails latest doc ... that's why I needed some clarification before going further so I just duplicated the Rails doc code into my app for testing ... and 1- it doesn't run 2- seems to be bad way as per your comment
can you clarify your comment # 2 taking this sample core_ext ? are the created files correct ? if yes , why the core_ext doesn't get loaded at all ? Le mardi 20 novembre 2012 18:26:53 UTC+1, Jordon Bedwell a écrit : > > On Tue, Nov 20, 2012 at 10:46 AM, Erwin <[email protected] <javascript:>> > wrote: > > in yoodle/lib/my_app/core_ext > > String.class_eval do > > def to_squawk > > "squawk! #{self}".strip > > end > > end > > > > and I have added in yoodle/config/application.rb > > config.autoload_paths += Dir["#{config.root}/lib", > > "#{config.root}/lib/**/"] > > > > but running in console > >> "AAA".to_squawk raises an error > > NoMethodError: undefined method `to_squawk' for "AAA":String > > > > Is there anything else not mentionned in the Rails doc ? > > 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. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/oc6ePWWLBecJ. For more options, visit https://groups.google.com/groups/opt_out.
