Add constructor injection for SocketHandler and its children
#1600
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I guess why not, although it makes the signatures much longer and complex to grasp, I do see the value/ease of use too. Can you please update the phpdoc to add the 5 new params in SocketHandler tho? No need to duplicate the descriptions everywhere IMO, as these get inherited, but it'd be nice to have details on the parent class. |
Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
boesing
force-pushed
the
feature/socket-constructor-injection
branch
from
09bda40
to
8ca1cdb
Compare
|
I've added the new arguments to phpdoc 🤙🏼 |
|
Thanks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey there,
I'd like to propose a PoC to allow constructor injection for the
SocketHandlerand its children.Is that something you want to support within monolog?
If not, I'd be fine with closing this. I can wrap around this and implement this as a feature in a dedicated abstraction layer tho.
Thanks in advance,
Max