The page says:
> This is now no longer an issue, Ruby 2.1 uses a method cache based on the class hierarchy, invalidating the cache for only the class in question and any subclasses.
How does this work with an instance of a class? Does it invalidate only that instance's method cache, or all instances in that class? If I do DCI-style:
@user.extend(PasswordConfirmable)
Does that blow away the cache for all User instances, or just that one?That class is below `User` in the hierarchy:
class User; def foo; "foo"; end; end
# => :foo
module M; def bar; "bar"; end; end
# => :bar
u = User.new
# => #<User:0x007f2e1abc9e00>
u.extend M
# => #<User:0x007f2e1abc9e00>
u.singleton_class.ancestors
# => [#<Class:#<User:0x007f2e1abc9e00>>,
M,
User,
Object,
PP::ObjectMixin,
Kernel,
BasicObject]I'm curious as to whether the ruby-core team implemented method caches for every Object in the system (eg: every instance of User would then have its own method cache because they all would have their own singleton classes) or just objects that are instances of the Class class. I seem to doubt that the former happened because it seems like it would be expensive to maintain a cache for every object, that means a normal Rails request that generates 65,000 strings would all have their own method caches. Only instances of the Class class having their own method caches sounds more reasonable from a performance standpoint to me.
For what it's worth, I've been trying to get an answer about this from a ruby-core member, although my attempts have been quite lazy through Twitter.
Thanks to the Ruby team for all the hard work on 2.1, it looks like there's a lot of little changes in there.
$ ruby -v
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-darwin13.0]Specifically, I believe they're planning on breaking API compatibility within major version numbers.
Yes. Full details: https://www.ruby-lang.org/en/news/2013/12/21/semantic-versio...