трейты зло - трололо

выглядит как интерфейс

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

короче, жду когда в Kotlin тайпклассы впилят

https://github.com/Kotlin/KEEP/pull/87

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

Вроде просто переименовали, там не было никаких “особых фич”. Просто вышел java8 с default methods в интерфейсах и как-то оказало что фичи 1k1

Берём значит в одну руку маркерные интерфейсы, другой пишем к ним extension методы, реализуем где надо пустой инерфейс - вуаля, примешали

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

Жесть. А как это технически сделано, с точки зрения JVM?

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

А чем это отличается от тайп-классов?

Берём значит в одну руку маркерные интерфейсы, другой пишем к ним extension методы, реализуем где надо пустой инерфейс - вуаля, примешали

не

Жесть. А как это технически сделано, с точки зрения JVM?

принимается Object и делается switch на классе?)

Жесть. А как это технически сделано, с точки зрения JVM?

Без идей. Я почти уверен, что так же, как в котлине это делалось бы руками через делегацию в новом объекте.

Берём значит в одну руку маркерные интерфейсы, другой пишем к ним extension методы, реализуем где надо пустой инерфейс - вуаля, примешали

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

А чем это отличается от тайп-классов?

Насколько я понимаю, ничем -- это же аналог того, что хотят в котлине в виде тайпклассов.

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

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

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

Ну да, а там где не подумали используем композицию

Ну да, а там где не подумали используем композицию

За всех авторов библиотек не подумаешь ;)

Ну да, а там где не подумали используем композицию

Ну ты прикинь какой-начнется рай, когда компоратор не надо будет поставлять руками в https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/sort-with.html а он будет приходить implicit ? для любых типов

Ну да, а там где не подумали используем композицию

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

Ну ты прикинь какой-начнется рай, когда компоратор не надо будет поставлять руками в https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/sort-with.html а он будет приходить implicit ? для любых типов

Страшный сон

В точку -- по сути синтаксический сахар над композицией.

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

но это происходит неявно

так что лучше руками

странная логика

всё что за тебя делает компилятор лучше делать руками?

всё что за тебя делает компилятор лучше делать руками?

Нет. Но должно быть очевидно, что он делает.

Фух, а я уже запереживал, что холивара не будет.

ну вот посмотри на пропозал с тайпклассами

https://github.com/Kotlin/KEEP/pull/87

по-моему очевидно что там происходит

и никаких обёрток к тому же компилятор не создаёт

при этом система типов становится гибче

PROFIT

Я кстати тут подумал, а нельзя ли из expect/actual сделать тайп-классы для бедных ?

Нет, потому что явно надо указывать expect.

За всех авторов библиотек не подумаешь ;)

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

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

Да это же как extension-methods расширять они позволяют что угодно, а инкопсуляцию не нарушают

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

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

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

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

Ну и да -- я не спец по JVM и не знаю, как это работает в хаскелле, но чёт мне подсказывает, что там это ровно так же, как без трейтов это делают руками -- новый класс, держащий расширяемый как приватный мембер и делегирующее ему все вызовы, которые делает программист. Другое дело, что в Kotlin/JS и Kotlin/Native это может быть реализовано без оверхеда на синтетический класс и делегированные вызовы.

если коротко: не надо будет на каждый результат(шаг) continuation'a создавать объект (насколько я помню)

Оно же изначально так работает https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md#implementation-details

Оно же изначально так работает https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md#implementation-details

Я криво выразился, на самом деле. Попробую вечером нормально сформулировать )

https://github.com/JetBrains/kotlin/blob/rr/zarechenskiy2/compiler/testData/writeSignature/inlineClasses/simpleSignatureWithInlineClassTypesAsReference.kt And of course java.lang.Long for kotlin.Long?

Whoops, wrong thread.

До контрол-табался. Энивей, там вполне честные инлайн-классы, которые даже превращаются в примитивы, где не нужен null.

Whoops, wrong thread.

Удаление же есть

Дык я тут тоже писал об инлайн-классах, пусть будет.

А почему никто не любит использовать спринг в котлине? И какой тогда di использовать?

Бут же вообще очень удобный

А почему никто не любит использовать спринг в котлине? И какой тогда di использовать?

Kodein например? Boot вполне удобный, хорошо преднастроеный и можно довольно эффективно дополнять код остальными спринговыми фишками типа секьюрити. Но вот я хочу сейчас в проекте DI и gRPC, там spring лишним становится.

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

А почему никто не любит использовать спринг в котлине? И какой тогда di использовать?

мне недавно кидали вроде годное решение для DI в котлине, ща

вот https://github.com/MichaelRocks/lightsaber

в отличие от Kodein резолвит в компайл-тайме, поэтому по идее типобезопасно (не будет NPE в рантайме из-за того что нет соответствующего биндинга)

Часть даггера, написанная на котлине и использующая гредл-плагин вместо процессора аннотаций. Выглядит занятно :)

Без val это параметры конструктора, которые доступны только в пределах init

нет доступны еще в обявлении класса типа: val i:Int = paramI

нет доступны еще в обявлении класса типа: val i:Int = paramI

это тоже инициализация

вот https://github.com/MichaelRocks/lightsaber

Что-то застыла разработка, середина сентября - последняя активность

это тоже инициализация

ну да

Я криво выразился, на самом деле. Попробую вечером нормально сформулировать )

если у нас корутина — числодробилка то сейчас вместо примитивов надо возвращать boxed типы. это дорого инлайн классы позволят возвращать примитивы

До контрол-табался. Энивей, там вполне честные инлайн-классы, которые даже превращаются в примитивы, где не нужен null.

^

если у нас корутина — числодробилка то сейчас вместо примитивов надо возвращать boxed типы. это дорого инлайн классы позволят возвращать примитивы

Каким образом там, где Object, вернёшь примитив?

Каким образом там, где Object, вернёшь примитив?

а это уже вопрос реализации инлайн классов. этого я не знаю (не читал код)

а это уже вопрос реализации инлайн классов. этого я не знаю (не читал код)

Все suspend-функции возвращают Object. Чтобы можно было вернуть SUSPEND_COROUTINE.

а это уже вопрос реализации инлайн классов. этого я не знаю (не читал код)

ну котлин отказывается от примитива, от его понятия, но это не значит что он не заменит их на этапе компиляции, + сама jvm это может, как говорил Шипилев, преждевременая оптимизация зло если вы питаетесть оптимизировать неочевидные вещи (я перефразировал)

> сама jvm это может как?

Вернуть int там, где нужен Object? Не может.

можно например вместо инта создавать в методе тип результата long и какое то специальное значение использовать в качетсве SUSPEND_COROUTINE. но причем тут inline классы...

можно например вместо инта создавать в методе тип результата long и какое то специальное значение использовать в качетсве SUSPEND_COROUTINE. но причем тут inline классы...

Вот это вариант, тогда боксить придётся только long и double.

Интересно можно ли тогда заинлайнить Maybe

если у нас корутина — числодробилка то сейчас вместо примитивов надо возвращать boxed типы. это дорого инлайн классы позволят возвращать примитивы

Это что бы 100k засыпающих корутин на презентациях выполнялись еще быстрее? ?

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

?

Это что бы 100k засыпающих корутин на презентациях выполнялись еще быстрее? ?

не, это для всяких IO каналов, например :)

Это что бы 100k засыпающих корутин на презентациях выполнялись еще быстрее? ?

речь идет как раз про незасыпающие ?

речь идет как раз про незасыпающие ?

Вот я и не понимаю зачем там корутины, если реально большое кол-во cpu-bound операций. Корутины даже не могу засыпать в них, если не вставлять везде yeild/delay

Ну разве что сделать свои paralle-коллекции, как в java8, только на корутинах.

Ну разве что сделать свои paralle-коллекции, как в java8, только на корутинах.

А толку-то, процессинг коллекций как раз обычно работают без блокировок

> сама jvm это может как?

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

https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.22.1

еще один релиз небольшой

Вернуть int там, где нужен Object? Не может.

есть такое понятие JIT компиляция, я не говорю что не может вернуть Int (объект), а то что эта вещь может оптимизироватся, в пазлерах по джава была такая вещь, если инт -128 - 127 (вроде как, уже давно смотрел), то он обект берется из кеша

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

есть такое понятие JIT компиляция, я не говорю что не может вернуть Int (объект), а то что эта вещь может оптимизироватся, в пазлерах по джава была такая вещь, если инт -128 - 127 (вроде как, уже давно смотрел), то он обект берется из кеша

Ну да, мы знаем про JIT-компиляцию. Кэш Integer'ов явно прописан в исходнике класса, это даже не оптимизация VM. Ну вот как вместо объекта вернуть либо инт, либо специальное значение? Вернуть лонг :)

Ну да, мы знаем про JIT-компиляцию. Кэш Integer'ов явно прописан в исходнике класса, это даже не оптимизация VM. Ну вот как вместо объекта вернуть либо инт, либо специальное значение? Вернуть лонг :)

ну для начала можно возращать кешуруемый инт. Возращать лонг не варянт, так как jvm жестко прописывает команды, и для чтения лонга по акту нужно два вызова чтения, для этого (вроде) есть специальная команда в jvm. А вообще начинать писать на джава\котлин и думать о анбоксинге, дурустика; экономить памть в масивах там да есть смысл. А если сильно хочется ест специальные либы, которые прям нативный код позволяют делать, правда думаю в джава 9 они не будут работать, хотя хз, если не через Unsafe то будут работать

ну для начала можно возращать кешуруемый инт. Возращать лонг не варянт, так как jvm жестко прописывает команды, и для чтения лонга по акту нужно два вызова чтения, для этого (вроде) есть специальная команда в jvm. А вообще начинать писать на джава\котлин и думать о анбоксинге, дурустика; экономить памть в масивах там да есть смысл. А если сильно хочется ест специальные либы, которые прям нативный код позволяют делать, правда думаю в джава 9 они не будут работать, хотя хз, если не через Unsafe то будут работать

Это какой-то набор слов. Что значит «возвращать кешируемый инт»? Кешировать инты на стороне корутин?

Это какой-то набор слов. Что значит «возвращать кешируемый инт»? Кешировать инты на стороне корутин?

нет, инт кешируется в пределах, я писал ведь выше

тут дело не в котлине или корунтинах а в JVM

нет, инт кешируется в пределах, я писал ведь выше

Так что значит «возвращать кешируемый инт»? Не возвращать числа больше 127? Отличный совет.

Так что значит «возвращать кешируемый инт»? Не возвращать числа больше 127? Отличный совет.

это не совет, но может помочь

Тогда можно использовать Byte, у него весь диапазон кешируется.

Так что значит «возвращать кешируемый инт»? Не возвращать числа больше 127? Отличный совет.

кешируется, например 'Integer.valueOf()' вернет тот самый обект, если он в пределах, и не будет выделялсятся еще один обект

Тогда можно использовать Byte, у него весь диапазон кешируется.

как раз нет

это только для инта

потому-что часто используется

кешируется, например 'Integer.valueOf()' вернет тот самый обект, если он в пределах, и не будет выделялсятся еще один обект

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/Byte.java#Byte.valueOf%28byte%29