Hi Keegan, Yes, just one class (plus associated tests and doco). It's not internal exactly but you are right it is not ever seen by normal Groovy users. It's only used by folks building DSLs which are subsets of the Groovy language. To me the aliases are clearer in English, quite possibly much clearer for non-native English speakers, as well as being more neutral.
PR here: https://github.com/apache/groovy/pull/1282 Cheers, Paul. On Tue, Jun 16, 2020 at 12:14 PM Keegan Witt <keeganw...@gmail.com> wrote: > I've been reticent on this because I'm more pragmatic than political. > Please don't interpret this as belittling any particular position, I just > prefer to view this issue primarily through the lens of a pragmatic > technologist for this discussion (to the extent possible). For discussions > over beers; I'm always interested to hear people's reasons for > their political and religious beliefs. > > 1. It's *one* class we're discussing. If this were a major overhaul, > renaming things all over the place, I'd be quite reluctant. But let's keep > things in perspective. > 2. This is an internal class (correct me if I'm wrong, but that was my > interpretation, given the package). As such, its contract is not > guaranteed, and therefore its naming conventions can be changed without > overwhelming concern for compatibility. Conversely, as an internal class, > naming conventions aren't as critical, as very few people would likely need > to interact with it. Although clarity should always be the goal, even > internally. > 3. Most importantly, names should communicate intent as clearly as > possible, so the user can stop reading code/documentation and get on with > getting things done. In this case, both the old and proposed names seem > equally understandable (to my eye anyway). Usually, I'd consider this a > reason to change nothing. > > However, Anne, you might be right about "blacklist" being a cultural > term. My first knowledge of it comes from learning American history, where > "blacklist" referred to lists of people or materials seen as sympathetic to > the communist cause (particularly associated with the anti-communist > activities of Senator McCarthy). As I understand the etymology, it was > likely named "black" because black is the color of darkness (blackness and > darkness being almost synonyms); in Abrahamic religious traditions, associated > with evil (also a well understood cultural reference in America and > probably most western countries, given historical influences). Regardless > of possible connotations, it is clear the word has its origins in some > cultural-historical event(s), and so may not be clear to all readers. > > > I despise non-functional code changes without good reason, but if the > current naming convention is confusing to some (I can't speak to that, > given my cultural background), then let's make it clearer. If we can agree > the proposed naming convention is *at least equally clear* (even if it > doesn't roll off the tongue), then (particularly given the very limited > scope of this change and the fact we're also going to use aliases) I think > it makes sense to proceed. > > +1 from me > > On Mon, Jun 15, 2020 at 7:46 PM MG <mg...@arscreat.com> wrote: > >> Hi Ann, >> >> good points in general. >> >> With regards to "blacklist" I think we can assume that the non native >> speakers who actually did not know the term will be familiar with it by >> now*, since there is a successful TV show that is literally called "The >> Blacklist" (going into its 8th season), for which Wikipedia lists entries >> in 34 languages: https://en.wikipedia.org/wiki/The_Blacklist_(TV_series) >> :-) >> >> Keep groovying, >> mg >> >> >> On 15/06/2020 03:05, Anne wrote: >> >> 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 >> >> >>
