Таки есть пpикольный хак, чтобы pаботало. Вот так вот выглядит: https://programmingideaswithjake.wordpress.com/2016/08/27/improved-pattern-matching-in-kotlin/ В итоге на пpактике (пpишлось что-то поменять, но в целом почти так осталось, как в сэмпле выше): when (item.let(PlatformPlanEntity.isNext::get zip PlatformPlanEntity.status::get) .let(Tuple2P.Companion.iso<Boolean, TaskStatus>()::reverseGet)) { Pattern(Tuple2P<Boolean, TaskStatus>::a) -> { } Pattern(Tuple2P<Boolean, TaskStatus>::b andThen TaskStatus.None::equals) -> { } Pattern(Tuple2P<Boolean, TaskStatus>::b andThen TaskStatus.Failure::equals) -> { } Pattern(Tuple2P<Boolean, TaskStatus>::b andThen TaskStatus.Success::equals) -> { } }

Tuple2P соответственно тот же tuple2, только поддеpживающий матчинг.

Не то, чтобы сильно удобно, но в целом выглядит пpикольно.

А такое в пpинципе неpеализуемо на котлине? Я что-то написал по-пpивычке, а потом задумался минуты на две, почему "_" кpасным подсвечивает when (item.let(PlatformPlanEntity.isNext::get zip PlatformPlanEntity.status::get)) { Tuple2(false, _) -> { } }

Говорят в котлине не нужен пат мат, так что увы

Взять JS, там раньше промисы были, выглядело это похоже на rx. Потом в ES какой-то версии ввели async await, и лично мне с ними как-то удобнее было, гибче, читабельней Примерно также отношусь к rxjava и корутинам на jvm, код как-то гибче, свободнее, проще читается)

промисы уже не модно?

промисы уже не модно?

async await это обертка над промисами)

А что есть перфоманс из http клиентов? Пробовал ktor-http-client поверх Apache клиента (HttpClient(Apache)). Есть что-то ещё? CIO клиент что-то не завёлся из-за какого-то header в response незнакомого ему o_O Хочется минимум зависимостей и как минимум 1000 rps. В целях провести нагрузочное тестирование с одной тачки без всяких гатлингов, танков и прочего. Может есть готовые фреймворки для такого?

эх пропустил весь срач про корутины

эх пропустил весь срач про корутины

Как будто они тут редкость и сегодня следующего не будет

А что есть перфоманс из http клиентов? Пробовал ktor-http-client поверх Apache клиента (HttpClient(Apache)). Есть что-то ещё? CIO клиент что-то не завёлся из-за какого-то header в response незнакомого ему o_O Хочется минимум зависимостей и как минимум 1000 rps. В целях провести нагрузочное тестирование с одной тачки без всяких гатлингов, танков и прочего. Может есть готовые фреймворки для такого?

а ktor client + apache не справляются?

https://plus.google.com/111471886409455069782/posts/4AxzbjnuRs5

Внезапно

Примерной по той же причине, по которой современные языки как однин выпили поддержку GOTO

а return@label чем не goto?

а return@label чем не goto?

тогда break/continue тоже можно к goto приписать

тогда break/continue тоже можно к goto приписать

они же только внутри циклов живут, а return где хочешь дёргай

тогда break/continue тоже можно к goto приписать

Так и есть если что

https://plus.google.com/111471886409455069782/posts/4AxzbjnuRs5

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

Просто они более узкоспециализированные

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

Год назада мну тут не было и на котлине я не писал

Как-то это не явно, странно что в доках это не описанно большими красными буквами

Как-то это не явно, странно что в доках это не описанно большими красными буквами

ты именно про то что если без Runnable как в примере, то использование лямбды каждый раз новый объект создает ?

Ага

https://plus.google.com/111471886409455069782/posts/4AxzbjnuRs5

Надеяться на какие-нибудь гарантии по identity лямбды - ну такое себе. Как минимум, случайный захват чего-нибудь из окружения может всё изменить.

Как-то это не явно, странно что в доках это не описанно большими красными буквами

Вообще, выглядит довольно очевидно, что для изменения типа объекта нужно его обернуть.)

Вообще, выглядит довольно очевидно, что для изменения типа объекта нужно его обернуть.)

Выглядит просто как сахар, типа мы просто опускаем слово ранабл и котлин сам определяет

Выглядит просто как сахар, типа мы просто опускаем слово ранабл и котлин сам определяет

И каким образом он определит что это runnable?

По использованию?

Мы же объёвляем переменную зараннее. Если бы мы её сразу положили куда нужно, то тогда бы он определил

По использованию?

ТАКОГО язык делать не должен.

а return@label чем не goto?

Ну как бы это сказать... Всем. В первую очередь тем, что return/break/continue это _структурные_ конструкции. В отличие от goto они не позволяют сломать вложенность блоков кода (инкапсуляцию куска логики в блок кода), что существенно упрощает анализ логики программы для человека.

Ну как бы это сказать... Всем. В первую очередь тем, что return/break/continue это _структурные_ конструкции. В отличие от goto они не позволяют сломать вложенность блоков кода (инкапсуляцию куска логики в блок кода), что существенно упрощает анализ логики программы для человека.

Ну вообще, по запутыванию кода return@label ~= goto

Ну вообще, по запутыванию кода return@label ~= goto

Нет, потому что return@label - очень частный случай такого перехода

Соответственно классический goto просто за счёт ~безграничной ширины возможностей позволяет сломать куда больше по определению.

Ну энивей, ты не можешь просто читать код сверху вниз

Ну энивей, ты не можешь просто читать код сверху вниз

Ну... Return@label практически гарантирует, что ты увидел лейбл (и если ими не злоупотреблять, то это будет примечательно, и запомнится), к которому будет возврат, т.е. шансы запомнить скоуп/контекст такого return, кажется, относительно высокие. А вообще - well, shit, если уж на то пошло, любой сложный код читается не совсем линейно как минимум потому, что где-то могут вызываться другие методы/функции, и если тебе критично важно понимать, что в них произошло, то ты, наверное, будешь прыгать между этими самыми объектами/методами/функциями.

Ну... Return@label практически гарантирует, что ты увидел лейбл (и если ими не злоупотреблять, то это будет примечательно, и запомнится), к которому будет возврат, т.е. шансы запомнить скоуп/контекст такого return, кажется, относительно высокие. А вообще - well, shit, если уж на то пошло, любой сложный код читается не совсем линейно как минимум потому, что где-то могут вызываться другие методы/функции, и если тебе критично важно понимать, что в них произошло, то ты, наверное, будешь прыгать между этими самыми объектами/методами/функциями.

Про ""... практически гарантирует, что ты увидел лейбл..." вспоминается "А гренка в нашем ресторане называется крутон. Это точно такой же поджаренный кусочек хлеба, только гренка не может стоить 8 долларов, а крутон — может"

Про ""... практически гарантирует, что ты увидел лейбл..." вспоминается "А гренка в нашем ресторане называется крутон. Это точно такой же поджаренный кусочек хлеба, только гренка не может стоить 8 долларов, а крутон — может"

Здесь была ехидная утрированная шутка, что всё программирование - сахар над машинными кодами... Но в целом да, щито поделать

Здесь была ехидная утрированная шутка, что всё программирование - сахар над машинными кодами... Но в целом да, щито поделать

Ну так можно всю математику назвать сахаром поверх арифметики. Даже скорее поверх теории множеств.

Ну так можно всю математику назвать сахаром поверх арифметики. Даже скорее поверх теории множеств.

Ну на то она "ехидная и утрированная", да. Technically correct - best kind of correct.

Как на котлине правильно JMH запустить с состоянием?

Все попытки содрать чужие примеры кончаются Field "array" is declared within the class not having @State annotation. This can result in unspecified behavior, and prohibited.

Как на котлине правильно JMH запустить с состоянием?

кажется, annotation processing не видит аннотаций на котлине. Я писал JMH (по факту — точку входа в бенчмарки) на джаве.

Да у меня все работало в другом проекте без состояния

Здесь рушится на этапе генерации байткода

Хочу проверить скорость чтения/записи из Array<Int> и IntBuffer

О, откадил jmh до 0.4.5, все заработало

Видать что-то испортили

Хочу проверить скорость чтения/записи из Array<Int> и IntBuffer

Ставлю на то, что массивы те же самые. Разница в накладных расходах на боксинг

Не должно быть там боксинга.

в Array<Int> же будет

Подскажите что за типы с восклицательным знаком даже не знаю как это погуглить String!

Мм, рассчитываешь, что компилятор оптимизирует и сделает из него IntArray?

Подскажите что за типы с восклицательным знаком даже не знаю как это погуглить String!

Java типы, когда объект приходит из джавы

Подскажите что за типы с восклицательным знаком даже не знаю как это погуглить String!

Хрен знает нуллабилити тип

Подскажите что за типы с восклицательным знаком даже не знаю как это погуглить String!

Google "kotlin platform types"

Котлин должен боксинг съесть вроде как.

https://kotlinlang.org/docs/reference/java-interop.html#null-safety-and-platform-types

Разница 15 %

Котлин должен боксинг съесть вроде как.

нет, не в этот раз

Котлин должен боксинг съесть вроде как.

В каком месте?

ERROR: S client not available

как и в Java, примитивы (раз)боксятся автоматом, массивы — нет

Почему, я же IntArray оборачиваю, он внутре array примитивов

Array<*> — это всегда массив объектов, а *Array — примитивов

Почему, я же IntArray оборачиваю, он внутре array примитивов

Не понял, что ты оборачиваешь?

array = IntArray(10000) { it } arrayBuffer = IntBuffer.wrap(array)

а, сорри, неправильно написал исходно

Мы говорим о том, что Array<> всегда будет ссылки держать внутри

это да

то есть между int[] и IntBuffer такая разница?

да

У интбуфера есть очевидные накладные расходы

Сейчас еще проверю для нативного буфера

о

Вот этого я не ожидал совершенно

Benchmark Mode Cnt Score Error Units ArrayBenchmark.benchmarkArrayRead thrpt 10 26864.946 ± 1655.356 ops/s ArrayBenchmark.benchmarkBufferRead thrpt 10 30442.452 ± 3699.404 ops/s ArrayBenchmark.nativeBufferRead thrpt 10 29841.918 ± 2674.617 ops/s

Нативный -это просто аллоцированный и заполненный руками

Я ожидал, что он медленнее будет.

Вопрос возник для реализации многомерных массивов. Насколько вреднео использовать для этого буфферы

Вопрос возник для реализации многомерных массивов. Насколько вреднео использовать для этого буфферы

А чем плохо использовать массивы для этого?

Инлайн класс матрица ?

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

Для матрицы все сделано на масивах, речь об аналоге ndarray

NDArray ?

ага

https://github.com/altavir/kmath/blob/dev/kmath-common/src/main/kotlin/scientifik/kmath/structures/NDArray.kt

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

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

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

Ещё решейпинг решается иммутабельностью ?

Каким образом?