Skip to content
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

anagram: reimplement cases where candidates isn't a set #1943

Merged
merged 1 commit into from
Apr 15, 2022

Conversation

petertseng
Copy link
Member

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 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.

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.
Copy link
Member

@ErikSchierboom ErikSchierboom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm in favor of this change, as it seems to be clearer to me.

@BethanyG
Copy link
Member

BethanyG commented Feb 2, 2022

I am also in favor.

@SaschaMann SaschaMann merged commit 6373ab6 into exercism:main Apr 15, 2022
@petertseng petertseng deleted the anagram-dup branch April 16, 2022 20:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants