Комментарии 21
for (float i = 0; i <= 10; i += 0.1) {
// Do something with i
}Отличный способ выстрелить себе в ногу на погрешностях округления. Этот пример считает до 9.900002, в то время как Kotlin версия до 10.0.
Но отсутсвие нормального for-loop в Kotlin конечно убивает.
If же возвращает значение, зачем ещё нужен тернарный оператор? А если хочется проверить на null, есть :? fallback.
У меня после прочтения сложилось впечатление, что автору не нравится что в Kotlin не все как в Java. Возможно что это у многих, кто переходит с одного языка на другой, что-то новое, а хочется чтобы было как раньше.
Честно скажу, циклы, ternary выглядит как отличие от Java, C++, Javascript, PHP, что уже серьезный набор языков :-)
Думаю, во многих не си-подобных языках нет тернарного оператора.
Если верить хаскелевой вике, то в Хаскеле можно наколхозить тернарный оператор средствами языка.
Хороший аргумент, а почему Kotlin не Си-подобный язык, разве это так необходимо?
Если такой итератор нужен, то можно написать какую нибудь приблуду себе в проект, аля
for (i in 1..10 step 0.1) {}
infix fun IntRange.step(value: Double): Iterator
В "3. Побитовых операциях" у вас Java-код остался от предыдущего пункта. А в оригинале всё правильно.
В scala не хватает break / continue, особенно с меткой. break всё-таки реализован странным образом, но за 18 лет развития языка, наверно, можно было бы добавить некоторые типовые конструкции.
Что хорошо сделано в scala и чего нет в java/kotlin/rust - оператор unapply, позволяющий парсить строки например так ( вместо ParseInt, ParseDouble у меня используются более короткие имена объектов) :
object ParseInt{ def unapply(s:String):Option[Int] = {...} }
object ParseDouble{ def unapply(s:String):Option[Double] = {...} }
str split "\\s+" match{
case Array(ParseInt(a),ParseDouble(b),c) => ... // a:Int, b:Double, c:String
case Array(ParseInt(a),str) => ... // a:Int, str:String
case Array(ParseDouble(a),"+",ParseDouble(b)) => a+b // a:Double,b:Double
}
В Java тоже постепенно добавляют вот это: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
Пока что (после того, как выйдет JDK 18) это выглядеть будет так: https://openjdk.java.net/jeps/420
Unapply помечен как Future Work, видимо ещё пара релизов потребуется.
break / continue : о, да!
Особенно с учетом мультипарадигменности языка.
Хоть перечисления в третьей скале добавили. Но похоже, все загнется из-за нового "пиши как угодно" синтаксиса.
Всегда ненавидел тернарный оператор (сперва потому что никак не мог запомнить, где у него какая ветка, потом за то, что он в С/C++ работает _не так же_ как if-else)
И после сишных `int * ptr, const a, *const * b` у меня дергается глаз при виде множества объявлений на одной строке
Но понятно, что это все - вкусовщина.. до некоторой степени :)
Тернарный оператор сделает Kotlin менее читаемым и сломает чёткое разделение, что конструкции со знаками вопроса и двоеточиями это про null-safety, а if else для возврата значения по условию. Какая конкретно польза будет в тернарном операторе как в Java я так и не понял за все эти годы)
Никто не вспомнил неявное приведение к Int — ещё одно очень спорное решение. Ладно когда требуется присвоить значение меньшему типу, это требует явного приведения — логично. Но объявлять массив через (byte) 0x00, или не дать сравнивать someLong == 0 — вот это дичь какая-то.
В Kotlin мы можем сделать это, используя побитовые ключевые слова.
val twoPowerOf = 2 shl x var removeTransparent = 0xFF000000 or color
Не так уж и плохо. Просто это не совсем традиционно.
Вот и выросло поколение, не видавшее традиционного Паскаля.
Если вы используете цикл, вы делаете что-то экзотическое. Или что-то неправильное.
О да, Си-подобных циклов очень не хватает. В статье забыли про обязательное приведение Int к Long даже для обычного присваивания.
5 лаконичных синтаксисов Java, которых мне не хватает в Kotlin