Не вызывайте статс бота, ну позязязя

Вообще не знал, что это за зверь

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

Я бы тоже. А ведь есть чат learn .java для джавы :) и вот он не популярнее котлина..

Они где-то на одном уровне

Кто то обновлялся уже на версию котлина 1.1.3 в андроид проекте ? без проблем ?

пофикшены старые баги, добавлены новые

пофикшены старые баги, добавлены новые

http://skillprogramming.com/images/pictuers/bug_line_415_to_420.gif

у меня после обновления на 1.1.3 такая вот ерунда Error:Execution failed for task ':app:compileDebugJavaWithJavac'. > kotlin.jvm.internal.FunctionReference.<init>(ILjava/lang/Object;)V

и я не могу понят что это

а как из котлина делать нативные вызовы?

а как из котлина делать нативные вызовы?

extern вроде

Вместо native

external, спасибо)

а как работает inline для функций? там просто тело функции вставляется в место, где эта функция вызывается?

да

в байткоде даже этой функции не будет

а это работает, когда я внутри функции вызываю другую приватную inline функцию из этого же класса?

почему нет)

а то мне линт подсвечивает, что inline стоит делать только для лямбд

а то мне линт подсвечивает, что inline стоит делать только для лямбд

А нафига тебе просто inline? Hotspot все и так заинлайнит (или ART на android)

он правильно подсвечивает) инлайн это не волшебная пилюля оптимизации

он правильно подсвечивает) инлайн это не волшебная пилюля оптимизации

ну мне не оптимизация нужна, а просто избавление от лишнего метода )

а чем метод не угодил?)

ну так зачем иметь в apk лишние private методы, каждый из которых используется в одном месте? может лучше их сразу заинлайнить?

Разве на этапе сборки они сами не инлайнятся?

Разве на этапе сборки они сами не инлайнятся?

Вот это я бы тоже хотел узнать

Разве на этапе сборки они сами не инлайнятся?

Нет, хотя вроде в android можно proguard частично настроить для этого. Но если мы говорим про android, то это “экономия на спичках”, ведь какой-нибудь google play analytics + admob уже ~15k методов

Вот тут хорошее объяснение https://stackoverflow.com/questions/24923040/do-modern-java-compilers-jvm-inline-functions-methods-which-are-called-exactly-f TL;DR it should in most cases

В прогуарде вроде был флаг

Кстати, закрытость классов для расширения по умолчанию не нарушает принцип Open-closed SOLID?

Наоборот же, юзай extension-functions для расширения или delegate-methods/classes для композиции

В каком смысле закрытость? Экстендс нарушает как раз.

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

В каком смысле закрытость? Экстендс нарушает как раз.

Наследование по умолчанию недоступно

Значит не нарушает

Это вы случаем не про final classes by default?

А расширения нужны интерфейсам, а не классам, как в Swift. Это решает expression problem, без решения которой трудно следовать Interface segregation

Это вы случаем не про final classes by default?

да

Для тестирования, например, рекомендуется делать классы открытыми для наследования, то есть не объявлять их final.

Для тестирования, например, рекомендуется делать классы открытыми для наследования, то есть не объявлять их final.

зачем?

для мокито эта проблема неактуальна

зачем?

не final и с virtual by default

не final и с virtual by default

я понял, просто смысл такой рекоминдации

я понял, просто смысл такой рекоминдации

как раз фейки, видимо, делать удобнее

стабы в смысле?

стабы в смысле?

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

Так, приватный метод не инлайнит на этапе сборки aar

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

окей. ток я не вижу проблем сделать мок final класса того же

стаб мб не получится сделать, но зачем если есть мок)

окей. ток я не вижу проблем сделать мок final класса того же

ок. Но всё же, по мне так final by default нарушает open-closed? Или если есть extensions, то язык может себе такое позволить?

То есть концепция наследования по умолчанию считается нежелательной и повторное использование класса ограничивается

ок. Но всё же, по мне так final by default нарушает open-closed? Или если есть extensions, то язык может себе такое позволить?

http://3.bp.blogspot.com/-yQb2PmC63VY/VJmCl4aBI5I/AAAAAAAACPg/tZY6u4XSbtU/s1600/Why%2Bfavor%2Bcomposition%2Bover%2BInheritance%2Bin%2BJava.png

ок. Но всё же, по мне так final by default нарушает open-closed? Или если есть extensions, то язык может себе такое позволить?

Нет, не нарушает

С прогуардом тоже не инлайнит.

http://3.bp.blogspot.com/-yQb2PmC63VY/VJmCl4aBI5I/AAAAAAAACPg/tZY6u4XSbtU/s1600/Why%2Bfavor%2Bcomposition%2Bover%2BInheritance%2Bin%2BJava.png

так с интерфейсами тоже беда. Главная их проблема в Kotlin не решена

extension интерфейсов виртуальными методами ведь не поддерживается?

ок. Но всё же, по мне так final by default нарушает open-closed? Или если есть extensions, то язык может себе такое позволить?

допустим джошуа блох пишет что ставте везде файнал где только можно

Вообще, ocp связан с такими вещами как предусловия и постусловия и это имеет отношение к делу если ты таки собрался наследоваться. При этом если нельзя наследоваться — значит нельзя by design

Про проблему интерфейсов. Вы про то, что нет default методов?

допустим джошуа блох пишет что ставте везде файнал где только можно

После этого код на джаве стало читать намного удобнее, лол

Вообще, ocp связан с такими вещами как предусловия и постусловия и это имеет отношение к делу если ты таки собрался наследоваться. При этом если нельзя наследоваться — значит нельзя by design

предусловия и постусловия - это Liskov

Может быть кто-то подскажет: как в IntelliJDEA создать проект с gradle + kotlin + web-пакетом с META-INF и WEB-INF, так чтобы больше ничего вручную не приходилось создавать?

ERROR: S client not available

предусловия и постусловия - это Liskov

Ааа, верно, гоню

После этого код на джаве стало читать намного удобнее, лол

но это не точно

Из моего понимания SOLID-принципов, писать, полностью их придерживась, невозможно как минимум в Java, C# и Kotlin

Ничего, val введут и заживем

После этого код на джаве стало читать намного удобнее, лол

А если еще везде Nullable/NotNullable аннотации расставить, то вообще ?

Из моего понимания SOLID-принципов, писать, полностью их придерживась, невозможно как минимум в Java, C# и Kotlin

это все таки больше вопрос к программисту. имхо в языках выше все для этого есть

это все таки больше вопрос к программисту. имхо в языках выше все для этого есть

Написал я класс. Заимплементил интерфейс какой-нибудь. Затем мне нужно часть публичных методов этого класса в соответствии с 'реализации должны зависеть от абстракций' использовать в друго классе. Если я этот метод (или группу) методов не заимплементил при создании класса, даже, если эти методы там есть, подставить объект не получится.

Нууу, тут просто какая штука, solid про оо, в то время как сейчас идёт все более сильно влияние функциональщины

Написал я класс. Заимплементил интерфейс какой-нибудь. Затем мне нужно часть публичных методов этого класса в соответствии с 'реализации должны зависеть от абстракций' использовать в друго классе. Если я этот метод (или группу) методов не заимплементил при создании класса, даже, если эти методы там есть, подставить объект не получится.

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

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

задолбаешься обёртки делать каждый раз. В некоторых языках уже есть решение

особенно в котлине

by delegate

задолбаешься обёртки делать каждый раз. В некоторых языках уже есть решение

Про это вкурсе https://kotlinlang.org/docs/reference/delegation.html ?

Про это вкурсе https://kotlinlang.org/docs/reference/delegation.html ?

это костыли какие-то, нужно расширение интерфейсов задним числом

что значит расширение интерфейсов задним числом?

это костыли какие-то, нужно расширение интерфейсов задним числом

Есть пример такого на JVM? (есть теория что рантайм не потянет без адских костылей (типа groovy :)))

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

что-то типа extension, только абстрактными методами в Swift есть

структурная типизация в typescript, но здесь это не нужно

и бегать по всему проекту гадать откуда у итератора взялся метод print() ?)

Так сэкстеншнами то же самое

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

Новый интетфейс, наследоваться и все.

Зачем придумывать

Так сэкстеншнами то же самое

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

структурная типизация в typescript, но здесь это не нужно

Ну в Swift это из рантайма object-c (частично динамического), а TS это вообще на грани добра и зла (JS). В JVM все строго в стат. языках.

С прогуардом тоже не инлайнит.

ок, спасибо

что-то типа extension, только абстрактными методами в Swift есть

Это очень удобная вещь, которой в котлине не хватает. (Я про extension в swift - это бывшие "категории" в objectivec) Действительно, часто бывает, что класс обладает реализацией всех методов, которые декларирует интерфейс. И хочется этот класс использовать напрямую, не создавая для него обертку(обертка если наследование закрыто) В целом extensions в swift мне нравятся больше.

Это очень удобная вещь, которой в котлине не хватает. (Я про extension в swift - это бывшие "категории" в objectivec) Действительно, часто бывает, что класс обладает реализацией всех методов, которые декларирует интерфейс. И хочется этот класс использовать напрямую, не создавая для него обертку(обертка если наследование закрыто) В целом extensions в swift мне нравятся больше.

кто-то понял, о чём я )

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

кто-нибудь видел в котлине у Sequence аналог scan из rx?