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> 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> 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> >> wrote: >> >>> +1, that's a great idea! >>> >>> >>> On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau < >>> cedric.champ...@gmail.com> wrote: >>> >>>> +1 >>>> >>>> Le jeu. 11 juin 2020 à 16:56, Jeff Beck <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> 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
