As per Rails doc
( http://guides.rubyonrails.org/plugins.html#extending-core-classes )
my app being yoodle

I added in yoodle/lib

yoodle.rb
require "yoodle/core_ext"
module Yoodle
end

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 ?





--
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 rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/FFN6nkjcy_wJ.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jordon Bedwell at Nov 20, 2012 at 5:26 pm

    On Tue, Nov 20, 2012 at 10:46 AM, Erwin 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 rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Erwin at Nov 20, 2012 at 6:22 pm
    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 <yves_...@mac.com <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 rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    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.
  • Frederick Cheung at Nov 20, 2012 at 11:22 pm

    On Tuesday, November 20, 2012 5:26:53 PM UTC, Jordon Bedwell wrote:

    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

    Fred
    --
    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 rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/T0RWkpid0xEJ.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Frederick Cheung at Nov 20, 2012 at 11:18 pm

    On Tuesday, November 20, 2012 4:46:56 PM UTC, Erwin wrote:

    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

    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

    Fred

    --
    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 rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/G9PBF8RJG2cJ.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Erwin at Nov 21, 2012 at 9:27 am
    Thanks Fred for this clear feedback ...
    I did it (added require 'yoodle.rb' in my initializers/configuration.rb)
    and it works ...

    :-)))

    Le mercredi 21 novembre 2012 00:18:43 UTC+1, Frederick Cheung a écrit :
    On Tuesday, November 20, 2012 4:46:56 PM UTC, Erwin wrote:


    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

    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

    Fred
    --
    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 rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/cA_CP7G50Z8J.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedNov 20, '12 at 5:15p
activeNov 21, '12 at 9:27a
posts6
users3
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2021 Grokbase