В джавке с этим проще было

Не, там наоборот, еще хуже

Посмотри сигнатуры внутри библиотеки стримов

с точки зрения понимания - проще

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

out - использовать в методе, o in отдавать во вне

Это если declaration site variance

out - использовать в методе, o in отдавать во вне

можнобез анг ? В дажве, если я правильно помю, масивы инварянтны, а колекции нет

Наоборот же?

хмм, я их опять мог попутать, сейчас посмотрю

Ну дока говорит, что наоборот - in работает для получаемых типов

В джаве массивы коварианты (это вызывает проблеммы), а коллекции инвариантны

В джаве массивы коварианты (это вызывает проблеммы), а коллекции инвариантны

У меня ковариантые и контравариантные бывают тензоры в теории гравитации, массивы в эту ячейку памяти уже не лезут

https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82 это масивы

по ссылке слишком общий термин. и к нашему случаю там ничего не относится

хорошо я поищу доклад

https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B8_%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

Кажется, разобрался. in T - гарантия возможности использования наследников типа применительно к входящему контейнеру для записи в него out T - гарантия возможности применения (приведения к) более общего типа относительно входного типа T

Упомяните меня, как найдете, или в личку

Как то недавно здесь спрашивал, как люди справляются с миграциями пользуясь Exposed. Посоветовали использовать дополнительный инструмент управления миграциями, например FlyWay. Подключил себе FlyWay, но обнаружил что в бесплатную версию не входят откаты миграций. Кажется, что это очень важная вещь, потому что я уже сталкивался с ситуациями, когда, например, допустил ошибку в скрипте и миграция выполнилась только на половину, в таблицу версий записались изменения и откатывать изменения приходится руками. Да и вообще возможность откатить миграцию выглядит востребованной. Какую альтернативу FlyWay вы используете? Или все пользуются комерческой версией это либы?

Где он говорит обратное? На скрине одинаковые числа.

Не, разные, поговори еще раз

Как то недавно здесь спрашивал, как люди справляются с миграциями пользуясь Exposed. Посоветовали использовать дополнительный инструмент управления миграциями, например FlyWay. Подключил себе FlyWay, но обнаружил что в бесплатную версию не входят откаты миграций. Кажется, что это очень важная вещь, потому что я уже сталкивался с ситуациями, когда, например, допустил ошибку в скрипте и миграция выполнилась только на половину, в таблицу версий записались изменения и откатывать изменения приходится руками. Да и вообще возможность откатить миграцию выглядит востребованной. Какую альтернативу FlyWay вы используете? Или все пользуются комерческой версией это либы?

Не, разные, поговори еще раз

У тебя даже в флайвей либо накатывается файл миграции, либо нет. Поэтому проблем не будет с этим. Откат в флайвей именно работает для целых файлов миграции, а не для поломанных скриптов. Для поломанных скриптов есть транзакции внутри.

Что было? 350+ сообщений не почитаю(

Но в постгресе точно есть

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

Оно должно таки немного различаться

ну там за столько итераций наверное в одинаковый машинный прооптимизировало

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

Нет. JVM не может убрать итератор. Только создать на стеке.

хз, не эксперт, но производительность одинаковая получилась

так я сразу сказал что андроид это не JVM, она не гарантирует ее спецификаций

Где?

ну там за столько итераций наверное в одинаковый машинный прооптимизировало

Где?

а что в спефикации что то есть про arraylist + indexed\iterator loop?

вызов метода, вот компилятор пытается от него избавится, если ты посмотришь в форИчь то там обычный цыкл, и если он инлайнится, т произодительность -+ ==

Лучше бы сунуть сумму в чёрную дыру

эт куда?

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

Интересно было бы разобрать почему

Да и в Марии должен быть. Оракл и мссивэквел в платной поставке anyway. Тут скорее вопрос что зачем использовать такие базы где этого нет, и как вы вообще с такой базой живёте

пару раз прогнал, indexed на 0-10% быстрее

пару раз прогнал, indexed на 0-10% быстрее

А теперь добавь рандомной логику (не примитивную)

Вот это я понимаю допуски

За что купил за то и продаю

Ну вот, ты продаешь конкретный случай. Зачастую бизнес логика больше влияет на скорость чем цикыл, и этим стоит заниматься когда прижало, нужна скорость. Посмотри доклады Шипилева. Ну и если ты со старта циклы пыиаешь оптимизировать, может в с нада кодит, или напрямую инструкциями

Да я смотрел шипилева конечно. Продаю и что? Я открыто и явно написал что сравниваем

Да и зачем переписывать если можно сразу написать indexed

Да и зачем переписывать если можно сразу написать indexed

Я про то что ты сравниваешь конкретный пример

Говнокод который я сразу конверчу в нормальные циклы

Да я спрашивал конкретный пример, что я сделал не так?

К счастью в котлин изначально нельзя так писать