Comments 27
data class User(val name: String, val password: String) {}
val (name, pass) = getUser()
А что будет со второй строчкой, если я позже в User добавлю после имени, но до пароля еще, скажем, email? Код перестанет компилироваться? Или я внезапно получу в pass emailы?
val (name, pass) = getUser()
А что будет со второй строчкой, если я позже в User добавлю после имени, но до пароля еще, скажем, email? Код перестанет компилироваться? Или я внезапно получу в pass emailы?
И еще интересно если для защиты от подобных проблем будет требоваться чтобы использованы были все componentN, то будет ли способ явно «проигнорировать» часть из них, например так:
val (name, _, pass) = getUser()
вместо
val (name, email, pass) = getUser()
val (name, _, pass) = getUser()
вместо
val (name, email, pass) = getUser()
В текущей версии в pass будет записан email. Думаю, что Вы привели хороший довод в пользу того, чтобы требовать, чтобы все компоненты были присвоены (но какие-то можно было пропутстить).
Прадва, по некотором размышлении, не очень понятно, как это сделать, имея в виду, что data-классы никакие не особенные, у них просто есть соответствующие методы…
Я бы предложил выкинуть convention про componentN вообще из языка как привносящую слишком много хрупкости в программы. А в замен сделал бы что-то подобное:
предполагая, что это скомпилируется в:
Да и вообще, все неявные фишки языка (когда компилятор догадывается до чего-то сам), которые выглядят чрезвычайно привлекательно для быстрого прототипирования (тупо меньше кода писать), могут при этом очень незаметно для простого разработчика привносить много хрупкости и создавать много боли и страданий при дальнейшей поддержке.
val (name, pass) = getUser.(name, password)
предполагая, что это скомпилируется в:
val tmp = getUser();
val name = tmp.name();
val pass = tmp.password();
Да и вообще, все неявные фишки языка (когда компилятор догадывается до чего-то сам), которые выглядят чрезвычайно привлекательно для быстрого прототипирования (тупо меньше кода писать), могут при этом очень незаметно для простого разработчика привносить много хрупкости и создавать много боли и страданий при дальнейшей поддержке.
ой, я скобочки у getUser забыл. Имел в виду вот так:
val (name, pass) = getUseк().(name, password)
Поддерживаю. Data class определён с _именами_ полей, вот пусть они по именам и достаются. Привязываться к _порядку_ объявления, да ещё и неявно — это самому себе стелить грабли.
Вообще, при всём уважении к команде Котлина (и симпатии к языку), componentN — это уродство. Надеюсь, можно будет придумать какую-нибудь альтернативу. Например, var (a, b) = c автоматически заполнять, если c — это массив (список, итератор и т. п.), а var (foo: a, bar: b) = c или (a, b) = c.(foo, bar), если c — это объект (или хэш?).
Вообще, при всём уважении к команде Котлина (и симпатии к языку), componentN — это уродство. Надеюсь, можно будет придумать какую-нибудь альтернативу. Например, var (a, b) = c автоматически заполнять, если c — это массив (список, итератор и т. п.), а var (foo: a, bar: b) = c или (a, b) = c.(foo, bar), если c — это объект (или хэш?).
Не планируется ли «скрестить» мульти-декларации с конструкцией when так же, как это сделали с конструкцией for?
Не очень понятно, как это сделать, чтобы не возникало традиционной в таких случаях путаницы между объявлением переменной и ее использованием.
Например так:
Кстати, какой вариант синтексиса Вы использовали в статье дя выделения кода? Kotlin в списке нет.
when(obj) {
(name, email, _) is User -> println("User name: $name, email: $email.")
}
Кстати, какой вариант синтексиса Вы использовали в статье дя выделения кода? Kotlin в списке нет.
Надо только не "(name, email, _) is User", a «User (name, email, _)» — тип должен быть частью паттерна.
Так нету там паттернов. Точнее якобы есть, но там только проверка типа.
Более того ранее я слышал заявления, что реализации паттернов не будет.
А перед «is» я поставил в данном случае чтобы
1) «чтобы не возникало традиционной в таких случаях путаницы между объявлением переменной и ее использованием»
2) Чтобы не так явно намекать на scala.
Более того ранее я слышал заявления, что реализации паттернов не будет.
А перед «is» я поставил в данном случае чтобы
1) «чтобы не возникало традиционной в таких случаях путаницы между объявлением переменной и ее использованием»
2) Чтобы не так явно намекать на scala.
Есть хотя бы весьма примерная дата выхода версии 1.0 (скажем 2013-2014 или как-то так)? Я пробовал использовать язык в своих «игрушечных» проектах и в принципе остался доволен.
В нем больше ясности, больше понимания того, что «под капотом» происходит по сравнению с той же Scala. Scala прекрасный язык, просто переключиться на него после Н лет работы с Java весьма сложно.
В нем больше ясности, больше понимания того, что «под капотом» происходит по сравнению с той же Scala. Scala прекрасный язык, просто переключиться на него после Н лет работы с Java весьма сложно.
Мы планируем начать широко использовать Kotlin внутри JetBrains в 2013 году. Эта стадия будет называться Beta. Доступ к ней, естественно, получат все.
Дату релиза 1.0 назвать невозможно: она зависит от того, что выяснится в процессе апробации языка в бета-стадии. Если придется менять что-то серьезное, это может сильно задержать релиз.
Дату релиза 1.0 назвать невозможно: она зависит от того, что выяснится в процессе апробации языка в бета-стадии. Если придется менять что-то серьезное, это может сильно задержать релиз.
Я лично нетерпением жду новостей от JetBrains по вопросу Nemerle :) Было бы крайне приятно видть аналогичный пиар по этому прекрасному языку
А почему «мульти-декларации», а не «паттерн-матчинг»?
Потому, что от реализации сопоставления с образцом отказались.
Сделали свой when с проверкой либо на равенство, либо на тип.
Сделали свой when с проверкой либо на равенство, либо на тип.
Потому что это не паттерн-мэтчинг. Никакого сопоставления с образцом не происходит: только декларация переменных.
Настоящий паттерн-мэтчинг мы решили пока отложить.
Настоящий паттерн-мэтчинг мы решили пока отложить.
Настоящий паттерн-мэтчинг мы решили пока отложить.
А почему??
А почему??
Потому что это очень сложная штука, 80% пользы от которой без проблем покрывается тем, что есть сейчас: github.com/abreslav/introduction-to-kotlin/blob/master/kotlin-examples/src/_06_smart_cast/Eval.kt#L52
дык сейчас у вас вроде обычный if чуть засахаренный, насколько я вижу.
А PM в использовании ничуть не сложен.
Expr =
| Num of Integer
| Sum of Expr * Expr
| Mult of Expr * Expr
let evalWhen = function
| Num(x) -> x
| Sum(a, b) -> evalWhen(a) + evalWhen(b)
| Mult(Num(0), _) | Mult( _, Num(0)) | -> 0 // типа оптимизация вычислений. в вашем текущем синтаксисе это выльется во всякую совсем мутную писанину.
| Mult(a, b) => evalWhen(a) * evalWhen(b )
Причем мне кажется именно для задач анализа AST такое архиполезно. да и не только AST вообще в любой задаче где нуно хоть сколько нить сложные данные анализировать.
А PM в использовании ничуть не сложен.
Expr =
| Num of Integer
| Sum of Expr * Expr
| Mult of Expr * Expr
let evalWhen = function
| Num(x) -> x
| Sum(a, b) -> evalWhen(a) + evalWhen(b)
| Mult(Num(0), _) | Mult( _, Num(0)) | -> 0 // типа оптимизация вычислений. в вашем текущем синтаксисе это выльется во всякую совсем мутную писанину.
| Mult(a, b) => evalWhen(a) * evalWhen(b )
Причем мне кажется именно для задач анализа AST такое архиполезно. да и не только AST вообще в любой задаче где нуно хоть сколько нить сложные данные анализировать.
А как с производительностью компилятора и плагина? Есть изменения в лучшую сторону?
Новое ключевое слово 'data' — не феншуйно. Подозреваю, вы пошли на это с трудом.
Sign up to leave a comment.
Вышел Kotlin M3