Conversation
|
I like the idea but I'm not too fond of the API. Since this is Ruby, you'll want a Do you have some code where this change makes your life easier? def run
if should_profile?
profiler.profile(&method(:call_downstream))
else
call_downstream
end
end |
|
Yes, I use it (that's why I made it). If you don't like it — okay, it's just idea that helps me :-) It's true about unless and |
|
Just my two cents, but I don't care for the API either. 😕 I suppose my major concern would be with the duplication of language-provided constructs as methods. Also, if you have criteria that determines if and when profiling runs, I believe that shouldn't be the profilers concern. Perhaps, wrapping the profiler with your logic and conditions would be a clearer approach like @lmarburger illustrates. |
|
The vision that I've had is that the user of pilfer would have an entirely different class that would be responsible for deciding if a given call should be profiled or not. Something that I think would be really cool is if it were possible to signal to a given process to profile on demand, but I don't think that sort of logic makes sense to be in pilfer itself right now. |
Useful in cases like:
profile.profile_if(Rails.env.staging?, ...) { ... }profile.profile_if(current_user.admin?, ...) { ... }