This repository has been archived by the owner on Jun 17, 2024. It is now read-only.
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.
Bug 1803465 - extend isURLLenient to match IPv6 literals #4090
Bug 1803465 - extend isURLLenient to match IPv6 literals #4090
Changes from 13 commits
a4bc4e7
6ab5019
5202c23
1cd491a
9760f84
2e679f9
e5ad176
4e5ca51
674be27
329b7a5
8f11276
39f09b2
417bfeb
2f6a576
90ca11b
9591c66
0c6285a
b9a23a9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Sorry, I forgot to specify that in my previous comment: we are adding complexity with this annotation-like function, that I think we could replace with clear comments around the tests.
We could replace the use of
assertTrue(INVERT(isURLLike(xxx)))
byassertFalse(isURLLike(xxx))
. Those asserts could be gathered with a comment above explaining that the ideal regex should have the same result as the one inUrlStringUtils.kt
, but the current one gives a different result. Also explaining that we allow it for now, until bug 1685152 is fixed.What do you think?
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 intentionally kept assertTrue/assertFalse the same as the original tests, and replaced the comments with a programmatic annotation, in order to reduce the cognitive effort required to maintain a second copy. Your suggestion would increase complexity when both functions are considered.
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 do understand the idea and the value of trying to keep both tests as similar as possible.
Nevertheless, this is starting a new pattern in the codebase, and maybe we should try to follow the existing conventions instead?
Maybe we could get a second opinion from someone else? cc: @jonalmeida
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.
Hey! I agree with @titooan, I too would prefer avoiding new patterns. Adding these cases that should pass/fail can be in a separate section with a well-worded comment to explain that these should be have differently when the linked bug is fixed.
The felt complexity of both solutions are indeed subjective. In cases like this, I would recommend the advice of the code maintainers to decide what is the more preferred way, especially in terms of conventions the codebase follows. 🙂
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.
done.