и так можно, просто можно, это меня радует

Мы тебе о том, что Bar().ext() -- это буквально создать объект bar, вызвать на нём экстеншн-функцию и выкинуть объект bar. Это ожидалось?

Как известно, из буханки хлеба, пары антеннок и прочей мелочи можно собрать троллейбус, но зачем? :)

по принципу let{}, который в байт коде создает 2 ссылки, обсолютно согласен, тут их должно быть если я правильно посчитал аж 3 лижних, я и не спорил

Мы тебе о том, что Bar().ext() -- это буквально создать объект bar, вызвать на нём экстеншн-функцию и выкинуть объект bar. Это ожидалось?

А как же BarFactory?

А как же BarFactory?

Дык вызывается внешний экстеншн на T, который Foo, а внутренний вызывается на Bar, но с его результатом ничего не делают. Разве что если он сам в лямбде заберёт эту ссылку -- но это выглядит слегка пахнущим интерфейсом.

на самом деле была такая идея / - быстро | / - удобо читаемо если есть множество вызовов по сути одинаковых функций, ресурс не ограничен. companion object использовать нельзя, то почему бы упереться ну например так Foo() .extention<Foo, Foo.Bar> { doSomething() } .extention<Foo, Foo.Bar> { doSomething() doSomething() } .extention<Foo, Foo.Bar> { doSomething() }

*упороться, но по сути самое клевое в котлине что и так можно написать, всю программу

foo(strings = *arrayOf("a", "b", "c"))"Фрагмент из доков" что за звездочка перед методом?

может vararg?

да точно, Spread Operator.

То

foo(strings = *arrayOf("a", "b", "c"))"Фрагмент из доков" что за звездочка перед методом?

мерзкий синтаксис (((

мерзкий синтаксис (((

+

В планах сделать отдельную от ktor.io библиотеку с блекджеком и асинхронными сокетами.

Которые на select/epoll будут работать?

мерзкий синтаксис (((

spread operator из питона пришёл, и конечно было бы приятнее передавать как обычный варарг

spread operator из питона пришёл, и конечно было бы приятнее передавать как обычный варарг

Есть оператор ... Правда не в питоне

Который реально удобнее

ты немного путаешь, ... в джаве служит для объявления варарга, а spread оператор нужен для преобразования обычного массива в варарг

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

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

* может гораздо больше, чем просто передача массива, например: listOf(1, 2, 3, *arrayOf(4, 5), 6)

* может гораздо больше, чем просто передача массива, например: listOf(1, 2, 3, *arrayOf(4, 5), 6)

в любом случае это сводится к тому, что массив представляется в виде списка аргументов для варарга

В жаваскрипте для тех же целей используется ...

Имхо, выглядит лучше

Кто-нибудь тестировал, как gson-ом быстрее всего парсить? Руками или доверить gson-у?

Или вообще написать какой-то кастомный парсер?

"быстрее" в плане написания кода или производительности?

если у тебя жсон не в десятки мегабайт, то вообще без разницы как парсить

ты думаешь напишешь парсер быстрее чем гугловский гсон?)

и есть еще jackson :)

он на рефлекшене и типа слоу

ты думаешь напишешь парсер быстрее чем гугловский гсон?)

изи, см. dsljson или jsoniter

"быстрее" в плане написания кода или производительности?

Производительность

Кто-нибудь тестировал, как gson-ом быстрее всего парсить? Руками или доверить gson-у?

Рефлективно первый раз долго, потом терпимо. AST сравнимо с ним, но прожорливо. Стриминг утомительно писать.

Производительность

Gson не об этом.

Gson не об этом.

:(

:(

Даже так: JSON не об этом.

Ну. это я знаю

Я тут недавно плакался в других чатах, что долго парсится и ничего нельзя сделать. Использовался org.json, я взял jsoniter (который быстрее Gson). JMH показал разниу в несколько раз. В Android на старте был такой же результат или медленнее, а уже последующие разы — быстрее.

Кто-нибудь тестировал, как gson-ом быстрее всего парсить? Руками или доверить gson-у?

А что тормозит? Или тут ты решил заняться “преждевременной оптиизацией”

А что тормозит? Или тут ты решил заняться “преждевременной оптиизацией”

Преждевременная. :)

Привет всем! Такой вопрос: IDE рекомендует юзать run вместо блока в лямбдах. типа emitter -> run{} вместо emitter -> {}, для чего это нужно?

Рекомендует? Оно просто в результате некоторых рефакторингов там появляется (видимо что бы покрыть общий случай). Я если могу, то сразу удаляю.

ну если пишешь тупо в блоке, весь код в не серым цветом идет. По сути разницы никакой не чувствуется

значит че то не так пишешь

ну если пишешь тупо в блоке, весь код в не серым цветом идет. По сути разницы никакой не чувствуется

в котлине это не блок, а лямбда-выражение

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

ты думаешь напишешь парсер быстрее чем гугловский гсон?)

я написал https://github.com/wizzardo/json-benchmarks

изи, см. dsljson или jsoniter

jsiniter кстати какой-то странный, на одном тесте он был непозволительно медленным

и какой ваш?

jsiniter кстати какой-то странный, на одном тесте он был непозволительно медленным

Интересно. На каком?

я написал https://github.com/wizzardo/json-benchmarks

а когда планируете kotlinx.serializer добавить?

когда кому-нибудь кроме меня будет интересно, что лучше юзать для работы с json

ERROR: S client not available

Интересно. На каком?

https://user-images.githubusercontent.com/5871626/37311915-670c1a8c-2649-11e8-8906-2f44fc420246.png

https://user-images.githubusercontent.com/5871626/37311915-670c1a8c-2649-11e8-8906-2f44fc420246.png

Что такое citys?

citys?

cities?

угу

больше - лучше, он там чего-то совсем зафейлился, работал, ноо крайне медленно

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

а когда планируете kotlinx.serializer добавить?

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

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

Дико интересно это всё. Потому что я прочитал стриминг jsoniter'а вдоль и поперёк и он мне кажется дико быстрым.

Дико интересно это всё. Потому что я прочитал стриминг jsoniter'а вдоль и поперёк и он мне кажется дико быстрым.

ну такое, может он хорош на больших файлах, мегабайт на 100, хотя 2.5 мб парсит примерно полсекунды

ну такое, может он хорош на больших файлах, мегабайт на 100, хотя 2.5 мб парсит примерно полсекунды

Ты мерил стриминг, маппинг или дерево?

мерил парсинг в Map и Pojo, сериализацию из Map и Pojo

мерил парсинг в Map и Pojo, сериализацию из Map и Pojo

Я использую только стриминг, мне некогда маппить или собирать дерево)

напишишь бенчмарк? или хотя бы пример использования?

напишишь бенчмарк? или хотя бы пример использования?

дико некогда(

и так всегда)

Извините за офтоп, но вместо джейсон файлов по 100 мегабайт, не лучше ли парсить бинарные форматы, типа протобафа? Всяко быстрее будет. И места меньше.

Извините за офтоп, но вместо джейсон файлов по 100 мегабайт, не лучше ли парсить бинарные форматы, типа протобафа? Всяко быстрее будет. И места меньше.

Лучше. У JSON нет ни одного адекватного плюса по сравнению с ними. Но там, кто спользует ноду или пхп, этого не понять.

Лучше. У JSON нет ни одного адекватного плюса по сравнению с ними. Но там, кто спользует ноду или пхп, этого не понять.

Есть, это наглядность - его можно просто читать программисту

Но 100MB json очевидно не надо делать

Согласен, но если у тебя 100 мегабайтный файл, но наглядным он не будет...

Есть, это наглядность - его можно просто читать программисту

proto-файл + бинарные данные = такой же читаемый текст

proto-файл + бинарные данные = такой же читаемый текст

Ну ну, давай курлом посмотрим

можно еще csv всякие юзать

формат для бедных)