Skip to content
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

Removing hooks? #31

Open
cmtonkinson opened this issue Sep 8, 2017 · 5 comments
Open

Removing hooks? #31

cmtonkinson opened this issue Sep 8, 2017 · 5 comments

Comments

@cmtonkinson
Copy link

I don't see any (documented or not) method to remove a hook. Is this possible, even if not fully supported? How would I do this?

If I wanted to remove all Hooks by name, it looks like I might be able to run self._hooks[:hook_name] = nil but it's not clear that

  1. This is "safe"
  2. This wouldn't result in memory leak for a long-running process.

I know this is more a pub/sub workflow than hooking, strictly speaking, but it would be awfully helpful (to my current challenge). Lacking a proper solution or viable hack, I'll have to rip out this gem and replace it with a pub/sub alternative, which I don't look forward to.

@apotonick
Copy link
Owner

Hi Chris,

the _hooks object uses inheritable_attr which is "safe" to manipulate in subclasses. We do it all the time in many gems. What makes you think it could lead to memory leaks?

https://github.com/apotonick/hooks/blob/master/lib/hooks.rb#L25

@cmtonkinson
Copy link
Author

Thanks for pointing to the use of inheritable_attr (I'd missed that).

With respect to safety - I shouldn't have said "memory leak." Poor question asking on my part, I apologize. I should have instead asked whether you create any other references to the callable objects stored in _hooks, such that if I remove a hook and relinquish the last variable in my code which references to said callable, the runtime will be able to GC it.

@apotonick
Copy link
Owner

It's a valid, justified question! I had many memory leaks!..... with ActiveRecord haha! 😬

If you change the _hooks "content" in B, its superclass A will still reference all the objects, so GC won't pick up anything here. Are you planning to change hooks dynamically at runtime? What will happen to the superclasses?

@cmtonkinson
Copy link
Author

In my use case, I'm wanting to dynamically add-and-remove instance hooks. Like I said, I may be pushing the design boundaries of the gem to the breaking point.

@apotonick
Copy link
Owner

Uhm, no, no. I haven't worked with this gem for a long time, but I can't see why this wouldn't work.

Have you considered using Trailblazer's Operations for your use case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants