PE
Интересно, планируется ли nested destructuring
Какая-то дичь, nested destructuring)))
Size: a a a
2020 October 12
AL
Какая-то дичь, nested destructuring)))
А в чём проблема?
с#
Какая-то дичь, nested destructuring)))
val ((name, password), bot) = env
QH
Какая-то дичь, nested destructuring)))
ох, хотя бы ради консистентности очень хотелось бы такое
с#
val (acc, bot) = env
val (name, password) = acc
val (name, password) = acc
RI
val (acc, bot) = env
val (name, password) = acc
val (name, password) = acc
with(env) {
with(/*env.*/foo) {
// name, password, bot
}
}AA
Какая-то дичь, nested destructuring)))
Простой пример, бизнес кейс практически:
Логичнее было бы так:
data class Address(val street: String, val city: String)То есть, я вынужден деструктуризировать пользователя, а потом адрес.
data class User(val name: String, val address: Address)
fun main() {
val user = User("name", Address("street", "city"))
val (name, address) = user
val (street, city) = address
}
Логичнее было бы так:
data class Address(val street: String, val city: String)
data class User(val name: String, val address: Address)
fun main() {
val user = User("name", Address("street", "city"))
val (name, (street, city)) = user
}
с#
with(env) {
with(/*env.*/foo) {
// name, password, bot
}
}не костыль 👍🏻
AN
Так все дослушал, ребенка помыл. По поводу пропозала с мультиресиверами. Там есть несколько не вполне понятных моментов:
* Как лямбды обозначаются. Ну более или менее понятно, но все-таки
* Как осуществляется разрешение типов
* Как быть если в ресиверах дженерики и их надо разрешать
* Как лямбды обозначаются. Ну более или менее понятно, но все-таки
* Как осуществляется разрешение типов
* Как быть если в ресиверах дженерики и их надо разрешать
PE
Простой пример, бизнес кейс практически:
Логичнее было бы так:
data class Address(val street: String, val city: String)То есть, я вынужден деструктуризировать пользователя, а потом адрес.
data class User(val name: String, val address: Address)
fun main() {
val user = User("name", Address("street", "city"))
val (name, address) = user
val (street, city) = address
}
Логичнее было бы так:
data class Address(val street: String, val city: String)
data class User(val name: String, val address: Address)
fun main() {
val user = User("name", Address("street", "city"))
val (name, (street, city)) = user
}
имхо это всего лишь один из самых простых примеров, просто лично мое мнение что так код превратиться не в очень читаемый, я бы лично предпочел вариант вот через with даже
И пример всего-то с одним вложенным, а если больше наплодят) ну такое такое себе ИМХО
И пример всего-то с одним вложенным, а если больше наплодят) ну такое такое себе ИМХО
AN
Так все дослушал, ребенка помыл. По поводу пропозала с мультиресиверами. Там есть несколько не вполне понятных моментов:
* Как лямбды обозначаются. Ну более или менее понятно, но все-таки
* Как осуществляется разрешение типов
* Как быть если в ресиверах дженерики и их надо разрешать
* Как лямбды обозначаются. Ну более или менее понятно, но все-таки
* Как осуществляется разрешение типов
* Как быть если в ресиверах дженерики и их надо разрешать
Ключевой вопрос по разрешению остается - есть порядок или нет порядка. Что будет если актуальный ресивер закрывает оба типа
AM
Ключевой вопрос по разрешению остается - есть порядок или нет порядка. Что будет если актуальный ресивер закрывает оба типа
По идее есть порядок, так как каждый декоратор — заворачивание функции в функцию.
RI
не костыль 👍🏻
Без structural системы типов грош цена этой фиче. А то что она работает не по именам, а по позициям вообще делает бесполезной для широкого программирования. Чисто как замена get(0), get(1) в коллекциях. 0 usages в моих приложениях
AN
По поводу namespace, как тут модно говорить - огонь. Очень органично
AA
имхо это всего лишь один из самых простых примеров, просто лично мое мнение что так код превратиться не в очень читаемый, я бы лично предпочел вариант вот через with даже
И пример всего-то с одним вложенным, а если больше наплодят) ну такое такое себе ИМХО
И пример всего-то с одним вложенным, а если больше наплодят) ну такое такое себе ИМХО
А, ну да, конечно читаемее, если ко всему этому добавить ещё промежуточные переменные, как в моём примере. Они конечно добавят читаемости и понятности.
PE
Без structural системы типов грош цена этой фиче. А то что она работает не по именам, а по позициям вообще делает бесполезной для широкого программирования. Чисто как замена get(0), get(1) в коллекциях. 0 usages в моих приложениях
согласен
AN
По идее есть порядок, так как каждый декоратор — заворачивание функции в функцию.
Вопрос не в порядке оборачивания, а в порядке разрешения.
AM
Ну так это ж обычный нестинг, я не вижу, почему там не должно быть порядка.
AM
Но может, я и неправ.
PE
А, ну да, конечно читаемее, если ко всему этому добавить ещё промежуточные переменные, как в моём примере. Они конечно добавят читаемости и понятности.
Ну если добавить промежуточные да, но все равно, ну лично мне такое себе,но это я так, пукнул своим мнением))), я уверен что на такую фичу не однозначное мнение, да и мне кажется это оч тяжелая в реализации фича