diff options
| author | Edouard CHIN <edouard.chin@shopify.com> | 2018-07-03 23:15:30 -0400 | 
|---|---|---|
| committer | Edouard CHIN <edouard.chin@shopify.com> | 2018-07-03 23:29:43 -0400 | 
| commit | 6cf7a0b0e9eaaa57fba0b0cea0f3015664baa0d8 (patch) | |
| tree | d9db13530d8e292229e29e5be7280392b13764e9 /actionpack/test/dispatch/session/mem_cache_store_test.rb | |
| parent | 0a6b866ff2f45cea50598fc054763b89ea7affbe (diff) | |
| download | rails-6cf7a0b0e9eaaa57fba0b0cea0f3015664baa0d8.tar.gz rails-6cf7a0b0e9eaaa57fba0b0cea0f3015664baa0d8.tar.bz2 rails-6cf7a0b0e9eaaa57fba0b0cea0f3015664baa0d8.zip  | |
Use class_eval or instance_eval when triggering lazy load hooks:
- When lazy load hooks were triggered we were using
  `Object.instance_eval` which evaluates the block in the context of
  the class being passed. Most of the time that class was a
  `Class`. If one wants to define a instance method on the class then
  it wasn't possible.
  ```ruby
    class A; end;
    A.instance_eval do
      def foo
        puts 'bar'
      end
    end
    A.new.foo #> NoMethodError: undefined method `foo`
    A.foo #> bar
  ```
- This PR checks what object is passed when triggering the hooks and
  either call `class_eval` or `instance_eval`. My rational and assumptions being
  that if an instance of a class is passed, then the blocks needs to
  evaluate in the context of that instance (i.e. defining a method
  should only define it on that instance).
  On the other hand, if a Class or Module is passed when triggering
  hooks, then defining a method should define it on the class itself
- #32776 Pushed me to introduce this change
Diffstat (limited to 'actionpack/test/dispatch/session/mem_cache_store_test.rb')
0 files changed, 0 insertions, 0 deletions
