а как его инстацировать?

не ну в джаве же есть класс Void

* The {@code Void} class is an uninstantiable placeholder class to hold a

+

Я так понял речь о том что инстанс нельзя сделать

Void в джаве это Unit в котлине так?

а Nothing вообще отдельная вещь

Void в джаве это Unit в котлине так?

в джаве нет Unit)

Void в джаве это Unit в котлине так?

Void как понятия в Kotlin вообще нет. Когда ты возвращаешь Unit (или делаешь процедуру) ты возвращаешь инстанц синглтона. Др вопрос как это на байткод ложится и интеропт с Java.

просто было бы круто чтоб котлин не ругался если я явно не возращаю Unit из джавы

Система типов тут консинсентна

А в джаве есть void, и костыль Void

Void в джаве это Unit в котлине так?

void не инстанцируется unit инстнцируется nothing скорей всего существует на уровне системы типов котлина (без класса)

void не инстанцируется unit инстнцируется nothing скорей всего существует на уровне системы типов котлина (без класса)

это тоже неинстацируемый класс

хех

Nothing который

А в джаве есть void, и костыль Void

Этот костыль для генериков хорош. Допустим если нужно void метод обернуть в Callable, то создаем Callable<Void>, а из самой лямбды можем null вернуть.

да я его тоже только для дженериков применял

Вот как Nothing выглядит в джаве

public final class SuspendKt { @NotNull public static final Void test() { throw (Throwable)(new RuntimeException()); } }

fun test(): Nothing { throw RuntimeException() }

Этот костыль для генериков хорош. Допустим если нужно void метод обернуть в Callable, то создаем Callable<Void>, а из самой лямбды можем null вернуть.

Я так понимаю, это потому что дженерики появилсь не сразу и “обратная совместимость” не позволила правильно перепилить типы (пришлось костылить).

void не инстанцируется unit инстнцируется nothing скорей всего существует на уровне системы типов котлина (без класса)

Т.е. да, он существует только на уровне типов

как any?

вообще когда-нибудь планируют делать джаву ради людей, а не ради обратной совместимости

?

Ceylon

Я так понимаю, это потому что дженерики появилсь не сразу и “обратная совместимость” не позволила правильно перепилить типы (пришлось костылить).

Скорее всего да. У Джавы вообще много странных решений только из за обратной совместимости были придуманы

вообще когда-нибудь планируют делать джаву ради людей, а не ради обратной совместимости

Или речь о Java 2.0?

Было бы не плохо

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

Или речь о Java 2.0?

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

Хотя может возникнуть ситуация как с Питоном

а что там?

типа 3 вышел но никто не юзает?

Так вся фишка Java в том, что она почти не ломается от релиза к релизу. Рынок тех кто лучшая джава уже сформировался вроде, что им там делать

ну тогда джавы 2.0 не будет :(

а что там?

Многие библиотеки на 3-ю версию до сих пор не переехали, и приходится и 2-ую, и 3-ю версии паралельно развивать. У каждой из веток уже свой зоопарк библиотек.

будет 1.10 , 1.11 ...

Мое мнение что так, да

будет 1.10 , 1.11 ...

От этой нумерации давно отошли, теперь java 9, 10, 11

И ломать обратную совместимость никто не будет, в этом просто нет никого смысла

От этой нумерации давно отошли, теперь java 9, 10, 11

C 5-6 версии

И ломать обратную совместимость никто не будет, в этом просто нет никого смысла

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

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

Можно мягко ломать.

Выпилить, наконец, методы и классы, на которых @Deprecated поставили 20 лет назад.

Можно мягко ломать.

мягко напрягая компании переходить на новые версии?

C 5-6 версии

С 5 если я правильно помню

ну там было 5.0, потом уже 6, 7, 8, 9

Выпилить, наконец, методы и классы, на которых @Deprecated поставили 20 лет назад.

Да, правила выведения деприкешенов должны быть более жёсткие. Типа две версии и к чертям

От этой нумерации давно отошли, теперь java 9, 10, 11

Только если заранить проверку версии, то все по старому https://image.prntscr.com/image/703ad5e6912b4cdf9269cb414d55dd01.png

мягко напрягая компании переходить на новые версии?

Есть ещё причины использовать Java 4..7?

Сделали же JEP 277: Enhanced Deprecation Но язык это все равно не исправит.

Есть ещё причины использовать Java 4..7?

Конечно, например в андроиде

Сделали же JEP 277: Enhanced Deprecation Но язык это все равно не исправит.

Нет, но это как мне кажется правильный шаг

Конечно, например в андроиде

Там 6..8.

Там 6..8.

там 6, и есть только часть фишек из 7 и 8

там 6, и есть только часть фишек из 7 и 8

С 19 — 7, с 25 — 8.

С 19 — 7, с 25 — 8.

это только часть фишек

это не вся джава 7 или 8

об этом и Бреслав говорил

Там и не вся Java 6 :)

ERROR: S client not available

зато весь котлин

О_о неплохое сравнение)

Что-то я не пойму, интерфейсы миксинами стали? interface MyInterface { val prop: Int // abstract val propertyWithImplementation: String get() = "foo" fun foo() { print(prop) } } class Child : MyInterface { override val prop: Int = 29 }

Что-то я не пойму, интерфейсы миксинами стали? interface MyInterface { val prop: Int // abstract val propertyWithImplementation: String get() = "foo" fun foo() { print(prop) } } class Child : MyInterface { override val prop: Int = 29 }

ну иммутабельная проперти - просто абстракный геттер, а остальное - как дефолтные методы в 8ой джаве. https://kotlinlang.org/docs/reference/interfaces.html

раньше в java-интерфейсе методы не могли иметь реализации, я правильно понимаю?

да

«абстракции не должны зависеть от реализаций» - и бла-бла-бла

мне этот принцип нравился

на самом деле смысл файнал методов в интерфейсе небольшой, когда есть экстеншен методы да и просто топлевел функции

на самом деле смысл файнал методов в интерфейсе небольшой, когда есть экстеншен методы да и просто топлевел функции

default-методов?

а по контексту static-методов

забей. я думал их переопределять нельзя

народ. анко много методов с собой тащит?

5к :/

кто-нибудь в проде использует, есть камни подводные, кроме превью на которую пофиг

вопрос по анко. как там стиль у вью задать? есть что-нибудь из коробки?

вопрос по анко. как там стиль у вью задать? есть что-нибудь из коробки?

на название виджета смотри.

кто-нибудь в проде использует, есть камни подводные, кроме превью на которую пофиг

да вроде нет, хотя ничего такого сложное не верстал.

Привет всем смотрел коотеркнифе и ети строчки ни понял, ктота сможет обяснит private val Activity.viewFinder: Activity.(Int) -> View?get() = { findViewById(it) } private fun <T, V : View> required(id: Int, finder: T.(Int) -> View?)= Lazy { t: T, desc -> t.finder(id) as V? ?: viewNotFound(id, desc) }

кто-нибудь в проде использует, есть камни подводные, кроме превью на которую пофиг

Есть камни, созданные андроидом. Рекомендую посмотреть список issues на гитхабе — ИМХО, основные проблему — у AppBarLayout и у DrawerLayout с fitsSystemWindows.

вопрос по анко. как там стиль у вью задать? есть что-нибудь из коробки?

Посмотри в сторону horizontalProgressBar, например.

Привет всем смотрел коотеркнифе и ети строчки ни понял, ктота сможет обяснит private val Activity.viewFinder: Activity.(Int) -> View?get() = { findViewById(it) } private fun <T, V : View> required(id: Int, finder: T.(Int) -> View?)= Lazy { t: T, desc -> t.finder(id) as V? ?: viewNotFound(id, desc) }

А что тут объяснять?)

T.(Int) а это что?

T.(Int) -> View

+

Лямбда с ресивером, верно?

(Int) -> View? вот это я понял а что за дженерик еще с точкой

Лямбда которая вызывается у типа T , в которую передается Int и которая возвращает View?

T будет доступно в лямбде как this