More inclusive naming

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

Re: More inclusive naming

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 with

Re: More inclusive naming

+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

Re: More inclusive naming

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

Re: More inclusive naming

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

Re: More inclusive naming

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 pr

Re: More inclusive naming

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

Re: More inclusive naming

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

Re: More inclusive naming

+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

Re: More inclusive naming

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

Re: More inclusive naming

+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

Re: More inclusive naming

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 documentati

Re: More inclusive naming

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

Re: More inclusive naming

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 i