странно почему доступ к приватным членам из тестов захейтили. было бы киллерфичей)

всю идею юнит тестов сломать

инкапсуляцию по одному месту пустить вот так просто

странно почему доступ к приватным членам из тестов захейтили. было бы киллерфичей)

++ кто бы там что не говорил. идеи какие то.

инкапсуляцию по одному месту пустить вот так просто

а зачем инкапсуляция в тестах?

а зачем инкапсуляция в тестах?

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

Мне больше всего нравится оправдания разработчиков Kotlin: типа выведение типа везде - слишком сложная штука (разработчиков Typescript это не остановило), люди проголосовали за неизменяемые данные (на втором месте), но это сложно и мы ничего не обещаем...

в андроиде вон есть @VisibleForTesting

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

inline classes ?

шта?

шта?

а почему нет? аналогично инлайн функциям

типа все члены класса инлайниться будут?

профит какой?

Это получается типа typealias только с более строгой проверкой типа

правда думаю существенные ограничения будут

Там только 1 поле вроде в таких классах можно

профит какой?

не создавать объект

ну хз

смотря как сделают

типа для оптимизации фича?

инлайн для оптимизации как раз

значит да

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

профит какой?

Это же типа скаляризации в хотспоте. На старых андроидах и нетиве пригодится.

инлайн для оптимизации кто-то юзает?))) я ток в целях reified дженерик типов юзаю

зря

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

инлайн для оптимизации кто-то юзает?))) я ток в целях reified дженерик типов юзаю

лямбды очень эффективно работают благодаря инлайну

возможно итератор можно как-нибудь оптимизировать инлайном (хотя наверное нет)

Как однажды сказал Бреслав "я вижу ты редко оптимизируешь код" ?

лямбды очень эффективно работают благодаря инлайну

ну мне это компилятор сам за меня решает

в смысле?

ну мне это компилятор сам за меня решает

речь о том, что ты лямбду не сохраняешь для повторного использования, а пишешь её всегда заново

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

с удивлением обнаружил что в котлине нет "SAM conversions for Kotlin interfaces"

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

объект не создаётся же

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

я всегда считал, что несущественную, но это неточно

объект не создаётся же

и сколько же у меня мои апкшки будут весить после такой "оптимизации"?)

а в чистой джаве при передаче лямбды всегда создаётся объект?

в 8ой нет

когда возможно она инлайнится

в таблице деклараций инлайн не появляется

с удивлением обнаружил что в котлине нет "SAM conversions for Kotlin interfaces"

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

боксинг параметров?! WTF?

ну при вызове метода,все переданные аргументы кастятся к типу параметра

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

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

но писать анонимные классы для их реализации - много места

ну при вызове метода,все переданные аргументы кастятся к типу параметра

ок

за что люблю котлин так это за возможность писать class Foo : (A) -> B { ... }

так как (A) -> B - по-сути интерфейс

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

как написали выше - для лучшей самодокументированности. сигнатуры лямбды мало. неплохо дать нормальное имя

но писать анонимные классы для их реализации - много места

Анонимные классы, насколько я понимаю, нужны были в java, ниже 8-ой версии, где не было возможности передавать функции. В Котлине, где можно ещё и вне класса глобальную (свободную) функцию объявлять, нет нужды в анонимных классах

боксинг параметров?! WTF?

Лямбда в байткоде это же дженерик интерфейс просто. А всё знают какой в jvm трендец с примитивными типами и дженериками.

Лямбда в байткоде это же дженерик интерфейс просто. А всё знают какой в jvm трендец с примитивными типами и дженериками.

SAM как раз и есть?

SAM как раз и есть?

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

Кстати в Kotlin же можно давать имена параметрам лямбы? Где то это видел (через анатации что ли).

Кстати в Kotlin же можно давать имена параметрам лямбы? Где то это видел (через анатации что ли).

{ str: String -> ... }

так?

Кстати в Kotlin же можно давать имена параметрам лямбы? Где то это видел (через анатации что ли).

какие проблемы-то?

ERROR: S client not available

Нет, когда объявляешь сигнатуру метода который принимает лямбду.

не уверен, что это возможно

да и зачем

Нет, когда объявляешь сигнатуру метода который принимает лямбду.

fun foo(callback: (a: Int, b: Int) -> Int) так чтоли хочешь?

Котлин-бот говорит что этот код ОК (нет компа под рукой). Это хорошо, так что лямбы себя неплохо документируют.

неплохо

я из головы взял, но вообще должно быть ок

причем имена параметров подставяться автодополнением

все. sam не нужен

Так да, SAM-это java-костыль, если сигнатуры лямбд есть

A function type is written as above, or may have named parameters, if you want to document the meaning of each parameter. val compare: (x: T, y: T) -> Int = ...

A function type is written as above, or may have named parameters, if you want to document the meaning of each parameter. val compare: (x: T, y: T) -> Int = ...

вот это ток и не хватало)

A function type is written as above, or may have named parameters, if you want to document the meaning of each parameter. val compare: (x: T, y: T) -> Int = ...

пример из доки официальной какой-то идиотский, что-то декларации параметра типа не вижу

Что не так с этим кодом? Как правильно объявить кастомный сеттер? class Test(x: Int) { var x: Int = -1 set(value: Int) { if (value < 0) { this.x = value; }; } init { this.x = x; } } fun main(args: Array<String>) { var test = Test(-2); println(test.x); }

на какую строку ругается?

вроде у кастомного сеттера нельзя объявить тип входящего параметра

рекурсивный вызов сеттера

Присваивать надо не в this.x а в field в сеттере

+

Присваивать надо не в this.x а в field в сеттере

удалите неоднозначнсость в совете, здесь 2 таких места

ты доку то почитай

удалите неоднозначнсость в совете, здесь 2 таких места

в сетере через field присвайивай значение полю

удалите неоднозначнсость в совете, здесь 2 таких места

Внутри сеттера доступна переменная field, ей и присваивать

ты доку то почитай

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

Внутри сеттера доступна переменная field, ей и присваивать

Да, всё верно

https://kotlinlang.org/docs/reference/properties.html#backing-fields

Очень рад что все согласились что Sam костыль :)

Хорошо что они написали “we are not committing here to implementing any of these features in a particular time frame, or at all”

конечно не надо все пихать, что там наголосуют