A quick search did not turn up anything on Kotlin using bool instead of boolean. Do you have a link ? To me brevity - as long as readability/code comprehension does not suffer - is always a desirable feature.Otherwise Groovy's each would be forEach or forEachElement or maybe even applyClosureToEachElementInDefaultOrder.Other examples are println which should be printLine or printInNewLine. "bool" in C++ at least seems to be from slightly before 2000, btw. It seems the unwieldy "boolean" is actually the older term. And not a well choosen one at that, since due to allowed values of [true, false, null] in Java/Groovy the resulting algebra is actually not Boolean (https://en.wikipedia.org/wiki/Boolean_algebra) :-)
-------- Ursprüngliche Nachricht --------Von: Russel Winder <rus...@winder.org.uk> Datum: 23.07.18 13:04 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: bool On Mon, 2018-07-23 at 12:40 +0200, mg wrote: > I wanted to keep my mail concise, but also aliasing Bool = Boolean > was more or less implied, for consistency & brevity reasons. > I would also think that Java would introduce Int = Integer, or use > int = Integer in that case... When it comes to these sorts of discussion excessive brevity can leave a lot of stuff missing! Clearly Kotlin is going these routes to make Java types more like C++ types, but I am not convinced this is a good idea. Shrinking type labels just to save a few keystrokes, or to conform to a 1970s view of type names, doesn't strike me as a good rationale. If however you could point to some psychology of programming experiments that proved code using bool rather than boolean and/or Bool rather than Boolean increased speed of code reading and comprehension, then you get my wholehearted backing for the change. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
