Hi Ann,
good points in general.
With regards to "blacklist" I think we can assume that the non native
speakers who actually did not know the term will be familiar with it by
now*, since there is a successful TV show that is literally called "The
Blacklist" (going into its 8th season), for which Wikipedia lists
entries in 34 languages:
https://en.wikipedia.org/wiki/The_Blacklist_(TV_series) :-)
Keep groovying,
mg
On 15/06/2020 03:05, Anne wrote:
Hi all
I support (eventually) removing the terms 'blacklist' and 'whitelist',
though my primary reason is different to the reasons already stated,
and I thought it might be worth sharing why.
It's generally recommended that names in programming be descriptive,
and that cultural references be avoided in favour of terms more likely
to be understood by non-native English speakers. Blacklist and
whitelist go against both recommendations.
I've never liked the terms, because when I first encountered them
(well before Groovy existed) I found them very confusing. Why is the
bad list black and the good list white? To remember which is which,
initially I had to keep thinking of the saying "you can always tell
the good guy in a Western, he's wearing the white hat". And if the
white was the good one, then the black one must be the bad one. Yes, I
had somehow missed out on exposure to those terms as a child. I
suspect that's a good thing.
I never understood why anyone would use those terms in computing,
instead of more descriptive terms that also include what is being
black/white listed. For example, I'd prefer to see allowedHosts,
allowedModules, allowedIps, allowedTokens, allowedImports, ... which I
find much easier to understand at a glance. If whitelist is used
instead for all of these, surely most people's next thought is "what's
being whitelisted?".
Cheers,
Anne.
On Fri, 12 Jun 2020 at 09:52, Paul King <pa...@asert.com.au
<mailto:pa...@asert.com.au>> wrote:
As per my comments to Cos, I am inclined to remove the old names
slowly. I'll put together a PR where the new aliases become the
prominent ones but the old ones remain and are deprecated in 4.
Cheers, Paul.
On Fri, Jun 12, 2020 at 1:19 AM Andres Almiray <aalmi...@gmail.com
<mailto:aalmi...@gmail.com>> wrote:
+1 Agreed,
Aliases in 3.x (should we target 2.x if there's a 2.5.13?)
We know that Groovy 4.0 will break binary compatibility due to
removal of split packages. We can remove the old names in
Groovy 4.0.
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who
understand binary, and those who don't.
To understand recursion, we must first understand recursion.
On Thu, Jun 11, 2020 at 5:13 PM Guillaume Laforge
<glafo...@gmail.com <mailto:glafo...@gmail.com>> wrote:
+1, that's a great idea!
On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau
<cedric.champ...@gmail.com
<mailto:cedric.champ...@gmail.com>> wrote:
+1
Le jeu. 11 juin 2020 à 16:56, Jeff Beck
<beckj...@gmail.com <mailto:beckj...@gmail.com>> a écrit :
I find those aliases easier to understand. So I
think it's a great improvement.
Jeff
On Thu, Jun 11, 2020, 9:50 AM Paul King
<pa...@asert.com.au <mailto:pa...@asert.com.au>>
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.
--
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: https://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au <mailto:i...@coherentsoftware.com.au>
