anagram: reimplement cases where candidates isn't a set#1943
Merged
SaschaMann merged 1 commit intoexercism:mainfrom Apr 15, 2022
Merged
anagram: reimplement cases where candidates isn't a set#1943SaschaMann merged 1 commit intoexercism:mainfrom
candidates isn't a set#1943SaschaMann merged 1 commit intoexercism:mainfrom
Conversation
Short version: The focal question of this commit: **Should determining set membership be case-insensitive?** If yes, this commit makes it so. If no, this commit should be rejected. Long version: In exercism#1928 it was codified that the input `candidates` is a set of words. Recall that a set contains no duplicates. Recall that ever since July 2013, it has been the intent of this exercise that determining whether two words are anagram of each other should be case-insensitive: exercism/exercism@bf3e011 Recall that ever since January 2014, it has also been the intent that determining whether a word is an anagram of itself should be case-insensitive: exercism/exercism#1266 The next step is to consider the focal question of this PR: **Should determining set membership be case-insensitive?** If yes, that is consistent with the anagram relation. Then, two current cases are in violation because they contain multiple instances of the same word. These instances are the same, even despite that they have different letter case, becuse set membership is case-insensitive. If this is so, this commit rectifies, while preserving tested functionality. If no, then we are declaring that this inconsistency is acceptable because it simply means two different rules are applied in two different situations, but they are both done consistently: Set membership is case-sensitive. The anagram relation is case-insensitive. If this is so, then this PR should be closed, with the discussion serving as affirmation that the question has been duly considered. Please understand that the opinion of the author of this commit is deliberately and explicitly left unspecified. The reason for that isn't to avoid unfair influence, but instead because the author of this commit does not anticipate having an opinion on this matter either way.
ErikSchierboom
approved these changes
Feb 2, 2022
Member
ErikSchierboom
left a comment
There was a problem hiding this comment.
I'm in favor of this change, as it seems to be clearer to me.
Member
|
I am also in favor. |
BethanyG
approved these changes
Feb 2, 2022
SaschaMann
approved these changes
Apr 15, 2022
This file contains hidden or 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
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.
Short version:
The focal question of this commit:
Should determining set membership be case-insensitive?
If yes, this commit makes it so.
If no, this commit should be rejected.
Long version:
In #1928 it was
codified that the input
candidatesis a set of words. Recall that aset contains no duplicates.
Recall that ever since July 2013, it has been the intent of this
exercise that determining whether two words are anagram of each other
should be case-insensitive:
exercism/exercism@bf3e011
Recall that ever since January 2014, it has also been the intent that
determining whether a word is an anagram of itself should be
case-insensitive:
exercism/exercism#1266
The next step is to consider the focal question of this PR:
Should determining set membership be case-insensitive?
If yes, that is consistent with the anagram relation. Then, two current
cases are in violation because they contain multiple instances of the
same word. These instances are the same, even despite that they have
different letter case, becuse set membership is case-insensitive. If
this is so, this commit rectifies, while preserving tested
functionality.
If no, then we are declaring that this inconsistency is acceptable
because it simply means two different rules are applied in two different
situations, but they are both done consistently:
Set membership is case-sensitive.
The anagram relation is case-insensitive.
If this is so, then this PR should be closed, with the discussion
serving as affirmation that the question has been duly considered.
Please understand that the opinion of the author of this commit is
deliberately and explicitly left unspecified. The reason for that isn't
to avoid unfair influence, but instead because the author of this commit
does not anticipate having an opinion on this matter either way.