Re: More inclusive naming

[Konstantin Boudnik]

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

Re: More inclusive naming

[Paul King]

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

Re: More inclusive naming

[Paul King]

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

Re: More inclusive naming

[Remko Popma]

+1

"In the end, we will remember not the words of our enemies, but the silence
of our friends."
-- Martin Luther King

Remko.


On Fri, Jun 12, 2020 at 2:17 AM Adam L. Davis  wrote:

> +1
>
> On Thu, Jun 11, 2020 at 12:12 PM Søren Berg Glasius 
> wrote:
> >
> > +1
> >
> > Best regards / Med venlig hilsen,
> > Søren Berg Glasius
> >
> > Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> > Mobile: +45 40 44 91 88, Skype: sbglasius
> > --- Press ESC once to quit - twice to save the changes.
> >
> >
> > Den tor. 11. jun. 2020 kl. 16.50 skrev Paul King :
> >>
> >> 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.
> >>
>
>
> --
> Adam Davis
> Web: github.adamldavis.com
>

Re: More inclusive naming

[Adam L. Davis]

+1

On Thu, Jun 11, 2020 at 12:12 PM Søren Berg Glasius  wrote:
>
> +1
>
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>
>
> Den tor. 11. jun. 2020 kl. 16.50 skrev Paul King :
>>
>> 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.
>>


-- 
Adam Davis
Web: github.adamldavis.com

Re: More inclusive naming

[Søren Berg Glasius]

+1

Best regards / Med venlig hilsen,
Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.


Den tor. 11. jun. 2020 kl. 16.50 skrev Paul King :

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

Re: More inclusive naming

[Jeff MAURY]

+1

Le jeu. 11 juin 2020 à 17:19, Andres Almiray  a écrit :

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

Re: More inclusive naming

[Andres Almiray]

+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 
wrote:

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

Re: More inclusive naming

[Konstantin Boudnik]

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

Re: More inclusive naming

[Guillaume Laforge]

+1, that's a great idea!


On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau 
wrote:

> +1
>
> Le jeu. 11 juin 2020 à 16:56, Jeff Beck  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  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 

Re: More inclusive naming

[Graeme Rocher]

+1

On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau 
wrote:

> +1
>
> Le jeu. 11 juin 2020 à 16:56, Jeff Beck  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  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.
>>>
>>>

-- 
Graeme Rocher

Re: More inclusive naming

[Cédric Champeau]

+1

Le jeu. 11 juin 2020 à 16:56, Jeff Beck  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  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.
>>
>>

Re: More inclusive naming

[Jeff Beck]

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

More inclusive naming

[Paul King]

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.