Max Home IndustryС продвижением Google Kotlin на поддерживаемый язык Android гораздо важнее то, как он будет развиваться. Теперь у нас есть результаты опроса JetBrain о том, что программисты хотят в языке.
По результатам опроса, проведенного в апреле с участием 850 респондентов, JetBrains надеется выяснить, чего хотят программисты дальше в Котлине. Конечно, опрос проводился до объявления Мэй о том, что Kotlin стал официальным языком Android, поэтому интересно предположить, сколько ответов получит опрос сейчас и насколько изменятся результаты.
Тремя явными лидерами, по мнению JetBrains, являются:
Литералы коллекции
Коллекции в Kotlin создаются путем вызова библиотечных функций, таких как:
listOf(1, 2, 3)или:mapOf(“foo” — “bar”, “baz” — “roo”)Это можно сделать более удобным, добавив специализированный синтаксис, например [1, 2, 3] для массива и что-то вроде: [“foo” = “bar”, “baz” = “roo”]
Преобразования SAM для интерфейсов Kotlin
Интерфейсы, имеющие один абстрактный метод (SAM-интерфейсы), могут быть естественным образом реализованы с помощью лямбд. Вот как работают лямбды в Java 8: когда они назначены интерфейсу SAM, он реализует их. Это называется преобразованием SAM.В Kotlin есть преобразования SAM для интерфейсов Java. Но для интерфейса, определенного в Kotlin, вы не можете назначить лямбду непосредственно ему. Предложение состоит в том, чтобы разрешить назначение лямбд интерфейсам SAM:
действие интерфейса
Действительно неизменяемые данные
У Котлина есть неизменяемые переменные (val, как указано в var), но нет языковых механизмов, которые гарантировали бы истинную “глубокую” неизменность состояния. Если val ссылается на изменяемый объект, его содержимое может быть изменено. Val-это просто переменная только для чтения, поэтому вы все равно можете изменять свойства объекта:val myVal = arrayListOf(1)myVal.add(2) // Интерфейсы только для чтения мутаций для коллекций несколько помогают, но нам понадобится что-то вроде модификатора только для чтения или неизменяемого для всех типов, чтобы обеспечить истинную неизменность. Что-то вроде:Синтаксис является чисто временным:класс Foo(var v: Int) неизменяемый класс Bar(val foo: Foo) // ошибка: изменяемая ссылка из неизменяемого класса
Эти три кажутся незначительными и полезными изменениями. Следующие три наиболее желаемых изменения были:
Срезы для списков и массивов это дало бы Python-подобную нотацию, например, данные[a:b] означают подсписок от a до b-1
Классы Inline/value-это, по сути, структуры для Kotlin, т. Е. классы данных, хранящиеся по значению, а не по ссылке.
многозадачность, позволяющая перехватывать несколько исключений одним блоком, например, catch (e: ExceptionA|ExceptionB)
Нет никаких обещаний, что все это будет реализовано, и, как говорится в сообщении в блоге:
«Действительно неизменные данные действительно очень желательны, но и очень жесткие, так что никаких обещаний нет. Два других кажутся послушными в обозримом будущем, и множественный улов также выглядит хорошей вещью для изучения. В любом случае, мы будем учитывать результаты при планировании нашей работы.»
На данный момент Kotlin-хороший компактный язык, и его использование очень напоминает мне о первых днях C#. Все языки имеют тенденцию раздуваться и наращивать функции, которые не являются строго необходимыми, но «строго необходимые» одного программиста-это «без которых может жить другой». Лучше всего использовать компактные логические языки. Будем надеяться, что Котлин останется худым и исправит только то, что сломано, если только не будет действительно хорошего случая для этой функции.
Майк Джеймс является автором предстоящей книги «Руководство программистов по Котлину», две главы которой уже опубликованы на I Programmer.