AL
Владимир, есть какие-то чуть более конкретные примеры, когда была боль без явных статиков? Просто отсутствие слова static в языке не добавляет боли в интеропе.
Size: a a a
2018 March 14
BP
Владимир, есть какие-то чуть более конкретные примеры, когда была боль без явных статиков? Просто отсутствие слова static в языке не добавляет боли в интеропе.
+
QH
от него как минимум хотят возможностей джавы + кучу сахара
Для этого есть Groovy, другой такой урод в Java-семье нам не нужен.
MA
Вопрос по @JvmDefault из доклада: а почему собственно в java-классах, имплементирующих kotlin-интерфейсы с дефолтными реализациями методов, не видны эти самые дефолтные реализации методов? Не силен в том, что делает котлин под капотом. И сопутствующий вопрос: можно ли будет пометить @JvmDefault дефолтный геттер для какого-нибудь свойства из kotlin-интерфейса, чтобы не переопределять его в классе, реализующего такой интерфейс?
VK
я же не знаю что для вас боль, для меня видеть компаньона в каждом втором классе с его раздутой конструкцией вместо компактной строчки это боль
BP
я же не знаю что для вас боль, для меня видеть компаньона в каждом втором классе с его раздутой конструкцией вместо компактной строчки это боль
вы пишете на джава или котлине?
VK
Для этого есть Groovy, другой такой урод в Java-семье нам не нужен.
это холивар. Вам не нужен - хорошо, кому то нужен - то же хорошо. Всем кушать хочется.
VK
вы пишете на джава или котлине?
на обоих языках, предпочитаю котлин, разумеется.
AP
Кстати да, лучше бы были нормальные статики вместо компаньонов
BP
на обоих языках, предпочитаю котлин, разумеется.
плохая практика, поэтому вам статик и нужен, я вот просто отказался юзать джавовский код в котлине
VK
плохая практика, поэтому вам статик и нужен, я вот просто отказался юзать джавовский код в котлине
это вы менеджерам попытаетесь объяснить почему нужно код за последние n лет переписать на котлин
QH
Вопрос по @JvmDefault из доклада: а почему собственно в java-классах, имплементирующих kotlin-интерфейсы с дефолтными реализациями методов, не видны эти самые дефолтные реализации методов? Не силен в том, что делает котлин под капотом. И сопутствующий вопрос: можно ли будет пометить @JvmDefault дефолтный геттер для какого-нибудь свойства из kotlin-интерфейса, чтобы не переопределять его в классе, реализующего такой интерфейс?
Дефолтные реализации для таргета 1.6 хранятся в синтетическом классе (типа SomeInterface$DefaultImpls), а вызовы к ним впиливаются компилятором.
AL
плохая практика, поэтому вам статик и нужен, я вот просто отказался юзать джавовский код в котлине
Ну, это уже вопрос использования, всё-таки до андроида он действительно продвигался как "Прикрути рядом и будет хорошо", так что не смешивать код это не всегда возможно.
BP
это вы менеджерам попытаетесь объяснить почему нужно код за последние n лет переписать на котлин
ну переписывать не нужно, просто старайтесь дальше писать на котлине, но вам самим нужно смотреть возможно ил это
BP
Ну, это уже вопрос использования, всё-таки до андроида он действительно продвигался как "Прикрути рядом и будет хорошо", так что не смешивать код это не всегда возможно.
не спорю
QH
это вы менеджерам попытаетесь объяснить почему нужно код за последние n лет переписать на котлин
Не нужно переписывать, можно продолжать писать на Java.
VK
безусловно, но старый код никуда не делся и в старом коде нужно как-то работать с новым
VK
Не нужно переписывать, можно продолжать писать на Java.
ну вы мне предлагаете вместо таблетки от головной боли взять топор
QH
ну вы мне предлагаете вместо таблетки от головной боли взять топор
да, выглядит это как-то так)
Ну суть в том, что на котлине нужно писать как на котлине.
Ну суть в том, что на котлине нужно писать как на котлине.
VK
так и представляю пресс релиз котлина: нравится джава - пишите на джаве