Question: How to "inflect once" for shared services?
beryllium opened this issue · comments
I'm running a Container with defaultToShared=true, and if I add an inflector, it runs the inflector every time the shared class exits the container. This is causing some unexpected behaviour with an EventDispatcher ListenerSubscriber class.
Is there something I should be doing differently so that the inflector doesn't run every time & end up subscribing dozens of duplicate event listeners? Or should the code be checking some combination of ->isShared() or a hypothetical new ->hasBeenInflected() helper before calling ->inflect?
Here is a possible approach that might sort of work: 4.x...beryllium:2021-08-13-container-track-inflected-state
However, it has some drawbacks and may not fully solve all possible scenarios.
(In my case, the ListenerSubscriber code I'm working with that would benefit from this change is using an accumulator, not a setter, and therein lies the issue. Multiple calls to the inflector and suddenly the whole system grinds to a halt because identical events are being dispatched multiple times.)
I think to be honest that making the assumption that a shared object does not need further inflection is the way to go. I need to take a look at whether I'd be comfortable with that in a minor release though. Give me a little time and I'll come back to you.
Sounds good! I've got a local workaround in place (using the power of method static variables 😂 😭 🤣 ), which is working well for the time being.
Encountered this issue again in a project, when I forgot to add the static variable workaround 🤦 Any recent thoughts on a solution? Let me know if I can help with a PR proposal or something.
@beryllium yeah I have a few things queued up to release, within a week 👍
Awesome! Glad to hear it :)
Sorry for the delay again, something came up, aiming for Monday release now (7 Feb)
Just hit this too. Is there anything we can do to help @philipobenito ?
I would also like to see this shipped. Please let me know if I can help :)
Sorry for the delay, been dealing with some health issues.
Planning a merge/release session next week so will look properly.
I've got a fix for this, going to roll it in to the 5.x release next week though as don't really want to touch 4.x at this point.
5.x won't change the public API so will be a very simple update process.
See #255
Also see this commit d486376 for the code change, I wouldn't recommend using 5.x yet as I may inadvertently change the public API without realising before release early next week.
Thanks for taking care of this!