replace blacklist and whitelist with denylist and allowlist in ERJava… #931
Conversation
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
…Mail classes and documentation I’ve provided cover methods for the old blacklist/whitelist methods so there can be graceful deprecation of these terms. This isn’t a change in function at all. There has been renewed discussion in many forums about the use of blacklist and whitelist and the connotations of bad/excluded and good/included. (blacklist addresses you want to exclude and whitelist addresses are those you want to include). Since this is a symbolic change and the use of “deny/allow” is a more clear indication of the intent and use of the functions, it’s worth making this change to these commonly used terms. Perhaps, over time, the negative associations will fade. Regardless of whether that happens, I think it’s worth using more clear terms here and being conscious of the unintended effects of some common practices.
|
@elemgee So, you are not up for translating the black and white references in the japanese javadoc? :--) O well. The changes look good and I cannot think of any reason not to merge it. Since I have not updated in a while, I will double-check and move on it soon. Let us know if there is anything you have thought of since you set this up. |
|
I’d give it a shot but I’m working mostly with Swedes these days so I can’t guarantee the translation
:-)
Larry
…On Jan 9, 2022, 2:03 PM -0600, Ray Kiddy ***@***.***>, wrote:
@elemgee So, you are not up for translating the black and white references in the japanese javadoc? :--) O well.
The changes look good and I cannot think of any reason not to merge it. Since I have not updated in a while, I will double-check and move on it soon.
Let us know if there is anything you have thought of since you set this up.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
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.
…Mail classes and documentation
I’ve provided cover methods for the old blacklist/whitelist methods so there can be graceful deprecation of these terms.
This isn’t a change in function at all. There has been renewed discussion in many forums about the use of blacklist and whitelist and the connotations of bad/excluded and good/included. (blacklist addresses you want to exclude and whitelist addresses are those you want to include). Since this is a symbolic change and the use of “deny/allow” is a more clear indication of the intent and use of the functions, it’s worth making this change to these commonly used terms. Perhaps, over time, the negative associations will fade. Regardless of whether that happens, I think it’s worth using more clear terms here and being conscious of the unintended effects of some common practices.