подскажите либу, для работы с xml нужно парсить в обе сторонызаписывая в файл и читая из файла

javax.xml

подскажите как добавить элемент в лист

Кури мануалы https://kotlinlang.ru/docs/reference/collections.html

Здравствуйте. Можете, пожалуйста, подсказать, можно ли спарсить все данные с андроид приложения как-то? Ну то есть больше вопрос в том, как получить ссылку для гет запроса по которой возвращаются, собственно все данные.(все участники + их личные данные но это наверное уже какой-то другой запрос нужно, имея их ID)

Здравствуйте. Можете, пожалуйста, подсказать, можно ли спарсить все данные с андроид приложения как-то? Ну то есть больше вопрос в том, как получить ссылку для гет запроса по которой возвращаются, собственно все данные.(все участники + их личные данные но это наверное уже какой-то другой запрос нужно, имея их ID)

Вам как минимум в @kotlin_mobile

А, ну да, что-то я баран, спасибо

А вообще какая-то странная задача, тут все зависит от конкретного приложения

о, наконец сделали в идее поддержку директорий нормальную для котлина

о, наконец сделали в идее поддержку директорий нормальную для котлина

А шо там (и в какой версии)?

ну это когда ты прям в src можешь себе сделать котлиновский файл и в нем задать нужный неймспейс

не создавая колбасу из main/kotlin/com/demo/blabla/module/..

Окейъ

это было в стайлгайде описано, но в идее не работало до недавнего времени

ну это когда ты прям в src можешь себе сделать котлиновский файл и в нем задать нужный неймспейс

Эм, а как тогда main и test разделять?

Эм, а как тогда main и test разделять?

src/ test/ resources/ build.gradle ...

https://github.com/ktorio/ktor-samples/tree/master/app/kweet вот как тут например

Действительно интересно выглядит, для новичков хорошо и на гитхабе удобнее. Надо будет как-нибудь тоже так сделать

не создавая колбасу из main/kotlin/com/demo/blabla/module/..

В что будет если пакет не указать?

можно просто main фигачить функцию без пакета)

из стайлгайдов: In pure Kotlin projects, the recommended directory structure is to follow the package structure with the common root package omitted (e.g. if all the code in the project is in the "org.example.kotlin" package and its subpackages, files with the "org.example.kotlin" package should be placed directly under the source root, and files in "org.example.kotlin.foo.bar" should be in the "foo/bar" subdirectory of the source root).

Интересно, а для ведра это сработает?

а че б и нет, это в градле настраивается

sourceSets { main.kotlin.srcDirs = [ 'src' ] test.kotlin.srcDirs = [ 'test' ] main.resources.srcDirs = [ 'resources' ] }

Кто-нибудь писал package-info.kt? У меня чёт ссылки (хоть в квадратных скобках, хоть @see не резолвятся, хотя в доках к классам всё ок

sourceSets { main.kotlin.srcDirs = [ 'src' ] test.kotlin.srcDirs = [ 'test' ] main.resources.srcDirs = [ 'resources' ] }

это ты папки флаворов скипаешь, а в тексте походу сказано скипать основной пакет

Кто-нибудь писал package-info.kt? У меня чёт ссылки (хоть в квадратных скобках, хоть @see не резолвятся, хотя в доках к классам всё ок

А это что за info ? На java 9 смахует

Кто-нибудь писал package-info.kt? У меня чёт ссылки (хоть в квадратных скобках, хоть @see не резолвятся, хотя в доках к классам всё ок

Так нельзя же, только на Java остаётся писать

А это что за info ? На java 9 смахует

Это от докки

Это от докки

+ аннотации для пакета

Kotlin не уважает пакеты, вот package-info и нету

Скажем так, котлин под пакетами понимает не директории

Кто-нибудь писал package-info.kt? У меня чёт ссылки (хоть в квадратных скобках, хоть @see не резолвятся, хотя в доках к классам всё ок

У самого котлина пакеты в отдельном ридми описаны

Никто не подскажет почему в данном случае компилятор не ругается на несоответствие типов, а приводит все к общему типу, в данном случае Any? val map = mapOf<Int, String>() map.getOrElse(1) { mapOf(1 to 1) }

Никто не подскажет почему в данном случае компилятор не ругается на несоответствие типов, а приводит все к общему типу, в данном случае Any? val map = mapOf<Int, String>() map.getOrElse(1) { mapOf(1 to 1) }

Наверное, потому, что он в такой ситуации выводит тип map как Map<Int, Any>, т.к. он не указан явно. Т.е. использование локальной переменной может повлиять на её выведенный тип.

Странно просто, мне казалось тип должен выводиться на основании переменной. При этом если ничего не возвращать, то все таки возникает "Type mismatch: inferred type is Unit but String was expected"

Странно просто, мне казалось тип должен выводиться на основании переменной. При этом если ничего не возвращать, то все таки возникает "Type mismatch: inferred type is Unit but String was expected"

Проверил, дело не в этом. Теперь мне тоже интересно, почему так ?

Никто не подскажет почему в данном случае компилятор не ругается на несоответствие типов, а приводит все к общему типу, в данном случае Any? val map = mapOf<Int, String>() map.getOrElse(1) { mapOf(1 to 1) }

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/get-or-else.html inline fun <K, V> Map<K, V>.getOrElse( key: K, defaultValue: () -> V ): V Лямбда же должна возвращать String в этом случае, а не Map.

А, понял. У getOrElse типы ключей и значений могут отличаться от тех, которые у Map, т.к. это extension. И она приводится к Map<Int, Any>.

А происходит так потому, что тип V у Map помечен как out

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/get-or-else.html inline fun <K, V> Map<K, V>.getOrElse( key: K, defaultValue: () -> V ): V Лямбда же должна возвращать String в этом случае, а не Map.

Да, поэтому и спрашиваю, почему не заставляет String вернуть, а приводит все к Any.

А, всё.

Понял суть вопроса наконец-то.

А происходит так потому, что тип V у Map помечен как out

Модификатор out вроде не стоит. Или это неявно происходит?

Модификатор out вроде не стоит. Или это неявно происходит?

Он стоит в месте объявления класса Map. Declaration-site variance называется.

О, понятно тогда, спасибо)

Компилятор видит этот код так: val map: Map<Int, String> = mapOf<Int, String>() map.getOrElse<Int, Any>(1) { mapOf<Int, Int>(1 to 1) }

Компилятор видит этот код так: val map: Map<Int, String> = mapOf<Int, String>() map.getOrElse<Int, Any>(1) { mapOf<Int, Int>(1 to 1) }

Котлиновский типы не стирает разве? Я этим вопросом не задавался кстати

Котлиновский типы не стирает разве? Я этим вопросом не задавался кстати

стирает, jvm же

Котлиновский типы не стирает разве? Я этим вопросом не задавался кстати

Куда стирает? Вы про type erasure?

Куда стирает? Вы про type erasure?

Оно самое

Типы в генериках

Оно самое

Ну так оно в рантайме, после компиляции. Вся суть дженериков в JVM в том, что хотя бы компилятор их видит)

стирает, jvm же

На железе всё биты в триггерочках)

У самого котлина пакеты в отдельном ридми описаны

Хмм, а как предполагается добавлять эти ридми когда собираешься джарник с документацией?

Хмм, а как предполагается добавлять эти ридми когда собираешься джарник с документацией?

Наверное, вас интересует это http://kotlinlang.org/docs/reference/kotlin-doc.html#module-and-package-documentation

В твиторе пишут что видео со второго дня котлинконфа доступны

Наверное, вас интересует это http://kotlinlang.org/docs/reference/kotlin-doc.html#module-and-package-documentation

? спасибо

Так, а есть какая возможность ограничить набором констант область значений инлайн класса над стрингой?

ERROR: S client not available

Бл, понял что опять пытаюсь придумать замену енуму =(

Бл, понял что опять пытаюсь придумать замену енуму =(

Собственно, зачем?

А вы не хотели бы в котлине синтаксис енумов как в свифте?

Когда имя класса можно опустить

Собственно, зачем?

¯\_(ツ)_/¯

Так, а есть какая возможность ограничить набором констант область значений инлайн класса над стрингой?

можно. делаешь приватный конструктор и фабричный метод

А вы не хотели бы в котлине синтаксис енумов как в свифте?

хочу что бы енумы в котлине стали просто синтактичским сахаром и превращались в чонить другое при компиляции что бы не пришлось со всеми с кем работаю бодаться по поводу истерии про енму на андроеде =)))

который возвращает не твой InlineClass, а InlineClass?

хочу что бы енумы в котлине стали просто синтактичским сахаром и превращались в чонить другое при компиляции что бы не пришлось со всеми с кем работаю бодаться по поводу истерии про енму на андроеде =)))

может, пора просто прекратить истерию? А прогард сделает, что может

и тогда он все проверяет

можно. делаешь приватный конструктор и фабричный метод

хм... фабричный invoeke =)))

нуда

можно и так

может, пора просто прекратить истерию? А прогард сделает, что может

общестенность давит ) задралло нервы тратить на объяснения )

общестенность давит ) задралло нервы тратить на объяснения )

А общественность использует анонимные классы, анонимные функции, лямбды, метод рефы, проперти рефы, делегаты? Мне кажется, поводов биться в истерике очень много.

общестенность давит ) задралло нервы тратить на объяснения )

скажи общественности, чтобы принесла бенчмарки с пруфами

после прогарда

А общественность использует анонимные классы, анонимные функции, лямбды, метод рефы, проперти рефы, делегаты? Мне кажется, поводов биться в истерике очень много.

да, достаточнго просто в окна выглянуть или новости почитать =) но тема с енумами была разрекламированна сильно ("ты чооо, нам на ИО говорили что так низяяяя")

Мда. Неграмотность гугла усиливается неграмотностью общественности.

угу, они до сих пор доку как грейдл обновлять не пофиксили

у них там написано что надо просто версию в пропертях сменить

а то что надо бы джарник врапера сменить и gradlew скрипты обновить не слова =)

а то что надо бы джарник врапера сменить и gradlew скрипты обновить не слова =)

а надо?)

ну ./gradlew wrapper это делает +)

у них там написано что надо просто версию в пропертях сменить

именно так, ничего более

я с 2.1 до 4.10 апал просто в пропертях и все без проблем работает

ну оно конечно и так работает, но логично предположить что раз они таки что то меняют в джарнике и скриптах, то их тоже стоит держать обновлёнными

меняешь версию в проперти, а потом запускаешь ./gradlew wrapper (ну или сразу его с указанием версии куда апацца)

я вообще врапером не пользуюсь) вообще редко)

Учитывая, что я в последнее время слышу о clojure буквально отовсюду, ничего странного не вижу