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
