interface A { fun a() } interface B { fun b() } fun <T> f(t: T) where T : A, T : B { t.a() t.b() }

а с классом?

в плане с классом? заменяешь interface A на open class A и добавляешь тело для fun a() и компилится

Если я правильно посчитал, это число на два порядка меньше Long.MAX_VALUE :)

Ну, если нам надо будет его умножить на дробь вида 1.234 в рамках целочисленной арифметики, то сначала мы умножаем на 1234, потом делим на 1000, и опа )

Ну, если нам надо будет его умножить на дробь вида 1.234 в рамках целочисленной арифметики, то сначала мы умножаем на 1234, потом делим на 1000, и опа )

Ну да, тут уже облом. Но изначальный вопрос был про "помещается ли" :)

Ну long очень походит на мамкиного оптимизатора, это далеко не самая затратная часть приложения

чем BigDecimal-то людей не устраивает?

Вот вообще хз

Да

Аргументы против BigDecimal будут?

Аргументы против BigDecimal будут?

сложна много букв

сложна много букв

Уж вот в Kotlin с его экстеншенами на BigDecimal не сказал бы, что сложна и много букв

Уж вот в Kotlin с его экстеншенами на BigDecimal не сказал бы, что сложна и много букв

а как это решает проблему?)

а как это решает проблему?)

Ну выражения с использованием BigDecimal записываются так же, как и для Double. Никаких тебе многословных методов типа add, subtract, multiply и прочего. Плюс есть возможность перегрузить операторы +-*/, чтобы они ещё другие численные типы в качестве аргументов принимали и кастили их к BigDecimal

Ну выражения с использованием BigDecimal записываются так же, как и для Double. Никаких тебе многословных методов типа add, subtract, multiply и прочего. Плюс есть возможность перегрузить операторы +-*/, чтобы они ещё другие численные типы в качестве аргументов принимали и кастили их к BigDecimal

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

Аргументы против BigDecimal будут?

Сделайте BigDecimal a = 10 или сложите пару BigDecimal без магии операторов котлина (которые тут всё же, как я помню, не работают), или использовать без приведения типа там, где требуется int, long, byte (хотя казалось бы). Ну то есть вопрос в том, что эту штуку неудобно использовать как число.

Сделайте BigDecimal a = 10 или сложите пару BigDecimal без магии операторов котлина (которые тут всё же, как я помню, не работают), или использовать без приведения типа там, где требуется int, long, byte (хотя казалось бы). Ну то есть вопрос в том, что эту штуку неудобно использовать как число.

Потому что это не число:)

Уж вот в Kotlin с его экстеншенами на BigDecimal не сказал бы, что сложна и много букв

В котлине с этим очень круто

Навесил операторов и работаешь как с числом

Но без этого создается ощущение, что что-то тут не так

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

Вы не путаете BigDecimal и BigNiteger случаем?

Но без этого создается ощущение, что что-то тут не так

А когда вы с Double работаете у вас не создаётся ощущения, что без всей обвязки, реализующей его поведение, что-то с ним не так? Любое число - абстракция. Без операций над ним что-то с ним не так.

А когда вы с Double работаете у вас не создаётся ощущения, что без всей обвязки, реализующей его поведение, что-то с ним не так? Любое число - абстракция. Без операций над ним что-то с ним не так.

Согласен:)

Сделайте BigDecimal a = 10 или сложите пару BigDecimal без магии операторов котлина (которые тут всё же, как я помню, не работают), или использовать без приведения типа там, где требуется int, long, byte (хотя казалось бы). Ну то есть вопрос в том, что эту штуку неудобно использовать как число.

Мне кажется, что вы тоже путаете BigDecimal (что-то вроде действительных чисел) и BigInteger (что-то вроде целых чисел). Ну и плюс к тому, смотрите выше. Не думаю, что с Int вы легко бы писали выражения, если бы операторы для него не были реализованы на уровне языка, JVM и процессора

Согласен:) абсолютно:) но я говорил именно о том, что работа с ним в коде неуклюжая, если речь о Java:)

Согласен:) абсолютно:) но я говорил именно о том, что работа с ним в коде неуклюжая, если речь о Java:)

Но это канал про Kotlin :)

Вы не путаете BigDecimal и BigNiteger случаем?

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

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

А для double и long все перечисленные плюшки из коробки, да?

А для double и long все перечисленные плюшки из коробки, да?

они и так прикрастно укладываются в оперативку))

Что-то всё в кучу. И богатство операций, и производительность

Но это канал про Kotlin :)

Ну да:)

так в чем проблема-то?

сложна много букв

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

Легче в плане чего? Как по мне, так Big* довольно просто реализованы, с учётом требования: "с высокой точностью хранить большие числа и не особо беспокоиться о проблемах переполнения, потери точности и прочих болезней Long, Double и иже с ними"

Реализация Int и Long вообще говоря поганенькая, как мне кажется. Они молча "жрут" ошибку переполнения и тупо становятся отрицательными

Это на практике приводит к внезапным бесконечным циклам, отрицательным величинам там, где их быть не должно.

Оооо, только сегодня эта статья на хабре вышла, рофл

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

https://vk.com/wall-20629724_1118752

С Int и Long примерно та же история, как и со связью между шириной лошадиного зада и шириной железнодорожной колеи. Они пришли из ассемблерного представления чисел. Весьма низкоуровневые числа. При этом высокоуровневые языки болеют при работе с ними всеми проблемами этой абстракции, хотя напрямую с ассемблером никак не связаны

Легче в плане чего? Как по мне, так Big* довольно просто реализованы, с учётом требования: "с высокой точностью хранить большие числа и не особо беспокоиться о проблемах переполнения, потери точности и прочих болезней Long, Double и иже с ними"

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

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

Ну да. А вы про что? Про внутреннюю машинению этих классов? Так мне она без разницы с точки зрения пользователя.

Ну да. А вы про что? Про внутреннюю машинению этих классов? Так мне она без разницы с точки зрения пользователя.

ахах ну да, я про кишки)) тогда да экстеншены хорошо смотрятся, я думал речь идет о подмене алгоритмов всяких, mathcontext и прочих объектов) Согласен на все 100 можно управстить внешний интерфейс и сделать его более котлин френдли так сказать

Ну у этих то хоть кишки можно почитать, даже взять за основу чего-нить своего, если припрёт, а вот в кишки Int, Long и Double уже гораздо сложнее залезть. С точки зрения программиста на Kotlin/Java там вообще магия внутре.

Реализация Int и Long вообще говоря поганенькая, как мне кажется. Они молча "жрут" ошибку переполнения и тупо становятся отрицательными

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

@HeapyHop А это ок, что в канале Daily Kotlin ты выкладываешь запись доклада с Джокера, которая, помнится, пока предназначена только для тех, у кого был билет? Помнится, в письме с ссылкой прямым текстом просили не распространять.

@HeapyHop А это ок, что в канале Daily Kotlin ты выкладываешь запись доклада с Джокера, которая, помнится, пока предназначена только для тех, у кого был билет? Помнится, в письме с ссылкой прямым текстом просили не распространять.

Ты из jugru?

Ты из jugru?

Нет.

Мне просто искренне интересно, мнение джуговцев кажется очевидным. Ругаться или что-то ещё не хочу.

Если что-то не понравится, они сами напишут (тут же не плейлист все таки выложили)

Окей, я вас услышал. Спасибо за ответ.

https://t.me/kotlin_lang/62682

https://t.me/kotlin_lang/62682

Окей, спасибо ещё раз!

ну что, ребят, уже затащили корутины в прод??

давно ?

давно ?

огонь, как полет?

шикарно проблем, связанных с именно корутинами, не было

особенно годно они на clean arch ложатся (про андроид) во внутренних слоях suspend-функции и в презентере уже билдеры, их запускажщие и управляющие потоками работает быстро, работает стабильно

шикарно проблем, связанных с именно корутинами, не было

У меня проблема была с релизной сборкой, пришлось обновляться до 1.0.0-RC с переходом на Котлин 1.3

особенно годно они на clean arch ложатся (про андроид) во внутренних слоях suspend-функции и в презентере уже билдеры, их запускажщие и управляющие потоками работает быстро, работает стабильно

+++

У меня проблема была с релизной сборкой, пришлось обновляться до 1.0.0-RC с переходом на Котлин 1.3

ну на то они и RC, что != релизному стабильному статусу =)

ну на то они и RC, что != релизному стабильному статусу =)

не, проблема была именно в стабильной версии, но починили это в RC

не, проблема была именно в стабильной версии, но починили это в RC

Стабильная - это которая 0.30.2?

Стабильная - это которая 0.30.2?

Не помню

Проблема была с прогардом

.

ну что, ребят, уже затащили корутины в прод??

уже давно на бекенде

особенно годно они на clean arch ложатся (про андроид) во внутренних слоях suspend-функции и в презентере уже билдеры, их запускажщие и управляющие потоками работает быстро, работает стабильно

А с ретрофитом юзаете? Там же как я понимаю надо call adapter который deferred возвращает

А с ретрофитом юзаете? Там же как я понимаю надо call adapter который deferred возвращает

есть же такой

Если покопаться - даже найду

есть же такой

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

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

У Вортана в call adapter предусмотрена отмена запросов

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

Хм... но зачем, если там deferred?

Хм... но зачем, если там deferred?

Чтобы не писать await

И не переключаться на другую корутину

Писать suspend чтобы не писать await?

С suspend можно просто withContext(Common pool){}

С suspend можно просто withContext(Common pool){}

Ну тогда понятно:)

Писать suspend чтобы не писать await?

Ну с deferred вроде там ещё корутина создаётся насколько я понимаю, а с withContext нет

С deferred точно создается, а с withContext не знаю

С deferred точно создается, а с withContext не знаю

В любом случае создаётся корутина. WithContext отличается от runBlocking тем, что он засыпает, а не блокирует поток. А чтобы заснуть - нужна приостановка.

В любом случае создаётся корутина. WithContext отличается от runBlocking тем, что он засыпает, а не блокирует поток. А чтобы заснуть - нужна приостановка.

Разве?)

Разве?)

А как ещё?

А как ещё?

Просто переключил контекст исполнения и все, не?

На другой тред

Просто переключил контекст исполнения и все, не?

https://gist.github.com/indrih17/36af83f63f69de92f352a611715769c5 код запуска withContext

Внимание в конец

Внимание в конец

Хм, Окай. Только почему .txt?

Хм, Окай. Только почему .txt?

??

??

Это ты из сорцов корутина взял?

Это ты из сорцов корутина взял?

+

Что может быть не так? val a = resultList.sortedBy { it.date.time } date это java.util.Date, если другое поле указать то сортирует нормально...

Что может быть не так? val a = resultList.sortedBy { it.date.time } date это java.util.Date, если другое поле указать то сортирует нормально...

тебе точно этот time нужен?

почему нет?

однозначное сравнение