Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix `thread_mattr_accessor` share variable superclass with subclass #25681
The current implementation of
Current implementation set variable statically likes
Make variable name dynamic to use own thread-local variable.
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.
Aug 8, 2016
Let me double-check this patch, just in case.
class A thread_cattr_accessor :foo self.foo = 1 end class B < A end
before this change the attribute was shared/inherited:
B.foo # => 1
and after this patch the attribute is no longer shared/inherited:
B.foo # => nil
This interpolation has been there since the initial implementation.
Which documentation does the description of the PR refer to?
@dhh what do you think?
OK. And the sentence
also seems to match the new behaviour in my example.
Looking good then. The only thing that bothers me in these macros is that the documentation leaks the implementation (
@fxn on second thought, without the
@senny totally agree.
A reader without a writer is useless if the user is not supposed to use the private key directly. And viceversa, why write something you cannot read? I think the public interface here is the accessor, and the reader/writer would be private methods that help implement the accessor.
If you want something to be private you can issue a manual