-
Notifications
You must be signed in to change notification settings - Fork 185
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
Update README.md #78
base: master
Are you sure you want to change the base?
Update README.md #78
Conversation
Updated code style: - strict_types - final readonly class - promoted properties - NullLogger instead of dealing with null (thereby removing the null-pointer exception I added in 2019...) - handle \Throwable - short-array syntax
{ | ||
$this->logger = $logger; | ||
} | ||
$this->logger->info('Doing work'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to do modern PHP, IMO it's best to leave $logger nullable and call it conditionally with:
$this->logger->info('Doing work'); | |
$this->logger?->info('Doing work'); |
That avoids useless method calls and a useless NullLogger instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends.
That means:
- having your code riddled with "?->"
- depending on a static code analysis tool (like PHPStan or Psalm) to prevent nullpointer exceptions
I think this is more a question of deprecating "NullLogger" or not (which is out of scope for this PR).
Personally, I like to keep it simple and stick to OOP with DI, since it is language agnostic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why this package should deprecate NullLogger. Both NullLogger and the nullsafe operator are valid ways to solve the case of the optional logger in the constructor
Personally, I like to keep it simple and stick to OOP with DI, since it is language agnostic.
being language agnostic does not make sense when writing a code snippet for PHP.
And if you mean avoiding features that don't directly translate to other OOP languages, your argument is void IMO:
- you are using constructor promoted properties, which have a direct equivalent in very few other languages
- the nullsafe operator exists in most modern languages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a recommended way to handle with no logs - pass a null
, not NullLogger
?
Updated code style:
strict_types
void
returnnull
(thereby removing the null-pointer exception I added in 2019...)\Throwable