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
[10.x] Fixes Str::password()
does not always generate password with numbers
#48681
Merged
+34
−19
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
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
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
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.
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.
It seems to be sufficient to determine if a value is true or not:
Since there is no native PHP type declaration, it is safer to treat all truthy values as true.
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.
but the parameter isn't typehinted as
bool
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.
Yes, I rather think so, which is why
=== true
should be omitted. For example, if you pass(int)1
here, I think it should be handled astrue
because it is a truthy value.In a situation where either
true
orfalse
is determined, it seems somewhat unnatural that all truthy values other thantrue
would befalse
. It would be also consistent in the case of adopting a native PHP type constraint, where1
would be cast totrue
at the start of function execution.If we move to using native type constraints somewhere in the roadmap, using
=== true
at this stage would be a breaking change.https://3v4l.org/buI6E
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.
framework/src/Illuminate/Support/Str.php
Line 842 in 09137f5
What's your expectation with without
=== true
and the following example: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.
Str::password(numbers: 'nah');
should beStr::password(numbers: true);
because PHP treats"nah"
as truthy. The important thing is that we should follow the interpretation of the PHP standard, not determine "what should be true" at the the framework.You would be correct if Laravel were to adopt the rule of always treating truthy values other than
true
asfalse
, but it is not actually happened so far. I don't think there is a lot of code that judges=== true
for something received with@param bool $arg
, so I think that needs to be consistent throughout the framework.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 would disagree https://github.com/search?q=repo%3Alaravel%2Fframework%20%3D%3D%3D%20true&type=code
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.
@crynobone I see, that is certainly the case in some codes. But apparently it is not consistent across the board. Somewhat confused.
For the moment, I see that there seems to be no need to discuss this excessively here. I think this has been an off-topic discussion, but thank you for your patience.