Well said.
I would add to that, that in IT "blacklist" is a purely technical term,
with the "black" having imho no association to people. Even if etymology
can be problematic in such questions, I also could not find any
indication in the etymology of the word* that it has anything to do with
the much newer, special meaning of the word "black" for a subgroup of
the group of persons which have a higher amount of pigment in their skin
(since their ancestors lived closer to the equator and it protected them
against the damaging effects of sun rays, contrary to other people whose
ancestors had moved farther north, which meant that higher amounts of
pigment in their skin became an evolutionary disadvantage).
Apart from that many other areas exist where the color black is
associated with negativity, like (from the top of my hat) warning signs
of radiation/chemicals/etc being colored yellow-black, being afraid of
the dark, depression and songs about depression/loss like "Paint it
Black" by the Rolling Stones, Star Wars, Lord of the Rings, death in
many parts of the world, etc, etc.
In general negative associations with the term black - black is of
course e.g. also the color of cool, sleek elegance - seem utterly
impossible to remove, independent of whether one sees it as a good idea
or not. So I am very doubtful how much good such a move in Groovy would
do, and if it actually "will result in a better and more just world
somehow".
Here are two links on people who evidently disagree with me:
https://jmla.pitt.edu/ojs/jmla/article/view/490 (here a connection is
postulated between the first known use of the word "blacklist" and the
beginning of the slave trade, but no evidence besides temporal coherence
is given)
https://www.zdnet.com/article/uk-ncsc-to-stop-using-whitelist-and-blacklist-due-to-racial-stereotyping/
In closing, if one wants to change the situation of poor people in the
US, many of which are "black", my suggestion would be to introduce a
public school & university system which gives you a free & good
education (like it exists in many European countries), give people
access to universal health care (respectively do not dismantle the
efforts already made in this direction, derogatively dubbed "Obamacare"
by the right), try to keep people of all shades from starting to take
drugs, etc - and in general reduce the huge difference between the rich
and the poor. And, yes, of course, try to keep people who are clearly
unfit for being in a profession that is supposed to protect all people
out of the police force & prosecute them if they have commited a crime :-)
Cheers,
mg
*https://en.wikipedia.org/wiki/Blacklisting
https://www.etymonline.com/word/blacklist
https://www.macmillandictionaryblog.com/blacklist
https://en.wiktionary.org/wiki/blacklist
On 12/06/2020 05:05, Konstantin Boudnik wrote:
Thank you, Paul, appreciate the details! Aliases seem like a
reasonable way to go. Let's keep them both for a while and see how the
new stuff getting traction.
After all, forcing someone to use 'blacklist' or 'disallowed' seem to
be arbitrary and equally sub-optimal. The keyword in this case is
'forcing': in Apache we always strive to reach consensus (not through
the voting) and consensus doesn't mean we all have to wear the same
jackets or sunglasses as far as we keep on doing what we do best -
developing the software.
Here's my +0 to that effect.
--
With best regards,
Cos
On 2020-06-12 06:50, Paul King wrote:
I agree we should minimise breaking existing code. I suspect
deprecating in 4 but leaving around might be the best compromise. The
goal of the change is that anyone who doesn't want to see/use the old
aliases shouldn't have to. And we should make the new names the
prominent ones in the documentation. My understanding is that in some
cultures/languages "black" represents a sign of strength and perhaps
allowed/prohibited might not be considered neutral somewhere else.
So, it is difficult to be totally neutral, this proposal does seem to
provide terms that many would find more neutral, so having that
option seems like a good thing from my point of view.
Cheers, Paul.
On Fri, Jun 12, 2020 at 1:15 AM Konstantin Boudnik <c...@apache.org
<mailto:c...@apache.org>> wrote:
Hey fellas!
Wearing my hat of a software developer, using Groovy quite
extensively
for the last decade, I'd like to understand the ramifications of the
initiative:
- at some point I would have to go back and comb through my
code and
change/recompile everything that would be affected by the
proposed APIs
changes, right?
- no gain in performance, no improvements in the semantic
expressions
- just find/replace and recompile for the sake of it?
But hopefully it will result in a better and more just world
somehow. Am
I summing this up correctly?
--
Thanks,
Cos
On 2020-06-11 21:50, Paul King wrote:
> Hi folks,
>
> Given recent world events, there are numerous projects that are
taking
> the opportunity to use more inclusive terminology especially in
names
> within APIs. E.g. getting rid of things like master/slave,
> blacklist/whitelist, etc. While I have never witnessed any racist
> behavior in the Groovy community, it seems worthwhile to be as
inclusive
> as we can. I scanned our codebase and it seems that the only
potential
> candidate we have for such a change would be
in SecureASTCustomizer. But
> feel free to chime in if you think there are others.
>
> For backwards compatibility, I wouldn't propose to remove the old
names
> in the first instance, just provide friendly aliases. We can
deprecate
> and/or remove the current names later if we feel the need. Some
example
> aliases could be something like:
>
> tokensWhitelist => allowedTokens
> staticStarImportsWhitelist => allowedStaticStarImports
> importsBlacklist => prohibitedImports (or disallowedImports)
>
> Thoughts?
>
> Cheers, Paul.
>
a
