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