-
Notifications
You must be signed in to change notification settings - Fork 11k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix bug in translator replacements for strings that have the same beg…
…inning. Fixes #1114.
- Loading branch information
1 parent
f1bb329
commit 2d35eef
Showing
3 changed files
with
27 additions
and
0 deletions.
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
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
2d35eef
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.
Isn't there a simpler/faster way than that ? While we're still in dev I don't think backwards-compatibility matters that much.
2d35eef
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.
2d35eef
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 overall it isn't failproof, just a little less prone to errors, what I meant was while you're fixing the behavior, why not use a start and end delimiters so that it is actually completely secure ? And even if the sort is right I doubt it's faster than an
str_replace
.2d35eef
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.
2d35eef
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.
Well if you have any variable where right next to it is a piece of string which would make it match another variable, it would fail. Like if you have two variables
:foo
and:foobar
and want to write$foo. 'bar'
it will replace it by:foobar
.I'm not saying this isn't an extreme case, but while we're in beta and that things that were a lot larger got changed, I don't see the cost of one character being worth the risk of having this code just waiting to fail on something a little more complex. Like if you had the opportunity to change Blade syntax to have an opening and a closing tag and avoid all the regex problems you've had since Laravel 3, then I'd say breaking compatibility is better than constantly fixing holes in the syntax – it's the same thing here. If it's better and more failproof, then people will adapt the new syntax, everything doesn't have to be backward compatible.