-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global toggle to turn it off #31
Comments
@mbj Only disables adamantium when its a problem and only very fine grained. Example is deep freezing big JSON / YAML parsed deeply nested trees. For my business logic admantium is fully active. Through I normally use |
Interesting – thanks for your feedback! |
@moonglum Did you tried Its implementation is basically: class MyClass
def self.new(*arguments)
super.freeze
end
end This only touches the newly created object thats on stack / active cache line / whatever. Does not walk through your object graph causing costly cache misses. |
I think Adamantium::Flat is really interesting. You are using that in Anima, right? |
@moonglum no. Instances of Anima infected classes are not frozen by default. You can if you wanted via including |
Oh, cool. Have to look at Anima again! |
I suggest to add a global switch to deactivate Adamantium. If it is activated, all calls to
include Adamantium
will be noops.Reasoning:
@solnic and I talked about Adamantium when we met at RedDotRuby Conf. He said that one of the problems with Adamantium is that it has significant performance implications. Because of this, people like @mbj removed Adamantium when going to production. He said that Adamantium is more to help you learn and to check your applications not so much for having this functionality in production. We concluded that it should probably be a testing / linting tool rather than something running in production. With the proposed functionality, Adamantium would only be active when running the unit tests.
The text was updated successfully, but these errors were encountered: