И подозреваю, что сделать kotlin.Map + добавить его поддержку в синтаксисе не получится/не планируется? Как насчет того, чтобы в stdlib напихать extension методов? Изначально вопрос возник из-за того, что внезапно у Map нет first(), хотя есть iterator(). Конечно, все можно делать через entries, но я, наверно, сладкоежка и слишком избалован скалой :)
Скажите, а java.lang.String и kotlin.String — это тоже различия на уровне синтаксиса или разные классы? Если второе, то наверно похожий трюк можно провернуть и с Map, нет?
В своем первом комментарии я написал "С массивами как-то выкрутились же", пытаясь, может быть не совсем корректно, привести пример того, что в Kotline не все так, как в Java. В котлине нет int[] и прочих, и для interop с Java сделан специальный инструмент IntArray и т.д. Этим примером я неуспешно пытался заранее контр-аргументировать предсказуемый ответ "потому что в Java Map не является коллекцией" на мой вопрос "почему Map — не Collection в Kotlin?" Этим превентивным контр-аргументом я неуспешно пытался подтолкнуть отвечающего дать развернутое и подробное объяснение.
Прошу вас теперь все-таки ответить на мой основной вопрос в этой ветке:
Почему Map не является коллекцией в Kotlin?
Почему в stdlib / kotlin.collections есть:
List — это Collection
Set — это — Collection
Map — не Collection??
Я в курсе, что так в Java, и было бы неудобно делать интероп с Java и т.д. С массивами как-то выкрутились же.
Если посмотреть на интерфейс Collection:
package kotlin.collections
public interface Collection<out E> : kotlin.collections.Iterable<E> {
public abstract val size: kotlin.Int
public abstract operator fun contains(element: @kotlin.UnsafeVariance E): kotlin.Boolean
public abstract fun containsAll(elements: kotlin.collections.Collection<@kotlin.UnsafeVariance E>): kotlin.Boolean
public abstract fun isEmpty(): kotlin.Boolean
public abstract operator fun iterator(): kotlin.collections.Iterator<E>
}
то выясняется, что у Map не реализован только метод containsAll(), который очевидно реализуется из contains. Остальные либо уже есть, либо реализованы через extension.
Насчет implicit conversions — согласен (для тех, кому лень гуглить — вот пример). Насчет разумного — более-менее адекватно выглядит implicit conversion арифметики, например Int в Long, Double в MySuperDuperComplex и т.п. Кстати, в котлине придется явно указать преобразование.
Насчет мощности — мы, наверно, по-разному понимаем ее. В моем понимании мощность близка к выразительности и набору возможностей. И при таком раскладе — С не мощный, выстрелить элементарно, Haskel — мощный, выстрелить трудно.
Что мне ещё не понравилось (это не к выстрелам в ногу относится) — что нет clone/copy методов у коллекций
А то, вроде, несколько строк только написал, а уже забомбило. youtrack.jetbrains.com/issue/KT-11221
В документации прямо говорится, что это костыль, чтобы избежать лишних проверок. Вы можете некорректно сделать инъекцию, забыть вызвать setup метод — на 100% быть уверенным в том, что поле будет проинициализировано, нельзя. В статье я написал, что его вообще использовать не стоит.
Хорошо, а для чего его тогда, по-вашему, надо использовать? Цитирую документацию:
Normally, properties declared as having a non-null type must be initialized in the constructor. However, fairly often this is not convenient. For example, properties can be initialized through dependency injection, or in the setup method of a unit test. In this case, you cannot supply a non-null initializer in the constructor, but you still want to avoid null checks when referencing the property inside the body of a class.
To handle this case, you can mark the property with the lateinit modifier
Почему многие подумают, что Nullable — это замена Option, я написал в начале статьи.
Сигнатуру я могу прочитать. Вот только если бы этот момент был бы очевидным, читать бы сигнатуру не пришлось.
Аналог implicit здесь — extension method, если вы про implicit class. Если вы про что-то другое — можно пример?
Насчет закономерности мощность/возможность выстрелить я в целом согласен, хотя приведу два контр примера — C и Haskell.
9 пункт поправил, спасибо.
Использование этого оператора в любом виде подразумевает, что вы будете стрелять себе в ногу (получением NPE как в примерах или просто плохим кодом, где можно было использовать smart-cast или дополнительную переменную). Опишите хороший кейс для этого оператора, где выстрелить невозможно, если вы считаете, что упоминание этого оператора излишне.
Повторюсь: если инкремент нельзя так использовать, зачем тогда оставлять его как expression? В питоне, например, его убрали как раз из тех соображений, что на нем можно написать что-то неочевидное.
Эта тема вообще достойна отдельной статьи. Они ссылаются на спорный пункт Effective Java, который, в свою очередь, ссылается на другой спорный пункт Effective Java. При этом в других частях языка Effective Java может не выполняться.
Скажите, а java.lang.String и kotlin.String — это тоже различия на уровне синтаксиса или разные классы? Если второе, то наверно похожий трюк можно провернуть и с Map, нет?
Прошу вас теперь все-таки ответить на мой основной вопрос в этой ветке:
Почему Map не является коллекцией в Kotlin?
List — это Collection
Set — это — Collection
Map — не Collection??
Я в курсе, что так в Java, и было бы неудобно делать интероп с Java и т.д. С массивами как-то выкрутились же.
Если посмотреть на интерфейс Collection:
то выясняется, что у Map не реализован только метод containsAll(), который очевидно реализуется из contains. Остальные либо уже есть, либо реализованы через extension.
а) Работа с тамзонами — это боль и унижение. См, например, https://habrahabr.ru/company/mailru/blog/242645/ или https://habrahabr.ru/post/100741/ или http://stackoverflow.com/questions/178704/are-unix-timestamps-the-best-way-to-store-timestamps
б) что вы имеете под "вручную"? Конвертировать human-readable в timestamp и обратно? А ваша контвертация между конечным форматом и форматом для пользователя — это ли не велосипед с ручным приводом?
Кстати, укажите, где написано, что unix timestamp — устаревший подход, а ваш UTC — новый и хороший?
Насчет мощности — мы, наверно, по-разному понимаем ее. В моем понимании мощность близка к выразительности и набору возможностей. И при таком раскладе — С не мощный, выстрелить элементарно, Haskel — мощный, выстрелить трудно.
Почему многие подумают, что Nullable — это замена Option, я написал в начале статьи.
Сигнатуру я могу прочитать. Вот только если бы этот момент был бы очевидным, читать бы сигнатуру не пришлось.
Насчет закономерности мощность/возможность выстрелить я в целом согласен, хотя приведу два контр примера — C и Haskell.
9 пункт поправил, спасибо.