Size: a a a

2020 March 02

ИМ

Иван Макеев in KotlinLangRu
Mikhail Guryev
какая глубина тебя интересует ?)
Хотя бы как у тебя реализовываются var и val и в чем разница под капотом. Понимая что есть final, тебе будет проще понял разницу между ними.
источник

ИМ

Иван Макеев in KotlinLangRu
Mikhail Guryev
какая глубина тебя интересует ?)
И еще например, как у тебя на JVM реализовывается inline, которой по сути нет в Java. Могу ошибаться, но насколько помню за встранивание отвечает static.
источник

MG

Mikhail Guryev in KotlinLangRu
Иван Макеев
Хотя бы как у тебя реализовываются var и val и в чем разница под капотом. Понимая что есть final, тебе будет проще понял разницу между ними.
Не согласен. Во всех сишных языках есть понятие константности.
И знание именно джавы тут не играет большую роль
источник

QH

Quantum Harmonizer in KotlinLangRu
Иван Макеев
И еще например, как у тебя на JVM реализовывается inline, которой по сути нет в Java. Могу ошибаться, но насколько помню за встранивание отвечает static.
Ошибаешься на 146%.
источник

MG

Mikhail Guryev in KotlinLangRu
Да. Байт-код JVM - это важная штука. И для «глубокого» понимания котлина нужно разбираться, как же твой код переводится в него
источник

ИМ

Иван Макеев in KotlinLangRu
Mikhail Guryev
Не согласен. Во всех сишных языках есть понятие константности.
И знание именно джавы тут не играет большую роль
Не забываем про контекст Android'а.
источник

MG

Mikhail Guryev in KotlinLangRu
Иван Макеев
Не забываем про контекст Android'а.
Дадада..
Если ты импортишь любую либу, которая написана на джаве, то ты обязан хотя бы читать её уметь)
источник

ИМ

Иван Макеев in KotlinLangRu
Mikhail Guryev
Дадада..
Если ты импортишь любую либу, которая написана на джаве, то ты обязан хотя бы читать её уметь)
Почти все исходники Android SDK написаны на нем, даже новые фичи))
источник

MG

Mikhail Guryev in KotlinLangRu
Мне нравится, что при переходе на Котлин, джава всё-таки проникает в твой мозг. Но как-то постепенно и безболезненно.
источник

MG

Mikhail Guryev in KotlinLangRu
И это очень круто
источник

m

milssky in KotlinLangRu
Почти наверняка
источник

ИМ

Иван Макеев in KotlinLangRu
Quantum Harmonizer
Ошибаешься на 146%.
Действительно ошибся. Не static, а final. Вот выдержка из "Философия Java" - В более ранних реа­лизациях Java объявление метода с ключевым словом final позволяло компиля­тору превращать все вызовы такого метода во встроенные (inline). Когда ком­пилятор видит метод, объявленный как final, он может (на свое усмотрение) пропустить стандартный механизм вставки кода для проведения вызова метода (занести аргументы в стек, перейти к телу метода, исполнить находящийся там код, вернуть управление, удалить аргументы из стека и распорядиться возвра­щенным значением) и вместо этого подставить на место вызова копию реально­го кода, находящегося в теле метода. Таким образом устраняются издержки обычного вызова метода. Конечно, для больших методов подстановка приведет к «разбуханию» программы, и, скорее всего, никаких преимуществ от использо­вания прямого встраивания не будет.
источник

QH

Quantum Harmonizer in KotlinLangRu
Конечно.
источник

QH

Quantum Harmonizer in KotlinLangRu
Иван Макеев
Действительно ошибся. Не static, а final. Вот выдержка из "Философия Java" - В более ранних реа­лизациях Java объявление метода с ключевым словом final позволяло компиля­тору превращать все вызовы такого метода во встроенные (inline). Когда ком­пилятор видит метод, объявленный как final, он может (на свое усмотрение) пропустить стандартный механизм вставки кода для проведения вызова метода (занести аргументы в стек, перейти к телу метода, исполнить находящийся там код, вернуть управление, удалить аргументы из стека и распорядиться возвра­щенным значением) и вместо этого подставить на место вызова копию реально­го кода, находящегося в теле метода. Таким образом устраняются издержки обычного вызова метода. Конечно, для больших методов подстановка приведет к «разбуханию» программы, и, скорее всего, никаких преимуществ от использо­вания прямого встраивания не будет.
final — ни разу не inline. Если метод большой или холодный, он заинлайнен не будет. А если маленький и горячий, то даже виртуальность — не помеха.
источник

ИМ

Иван Макеев in KotlinLangRu
Quantum Harmonizer
final — ни разу не inline. Если метод большой или холодный, он заинлайнен не будет. А если маленький и горячий, то даже виртуальность — не помеха.
ок, если и  Брюс Эккель не прав, то каким образом вызывается механизм встраивания в Java?
источник

MG

Mikhail Guryev in KotlinLangRu
в общем случае, это JVM решает, заинлайнить ли твой джававский код или нет :)
можно повысить свои шансы, сделав метод статичным
https://stackoverflow.com/questions/2096361/are-there-inline-functions-in-java
источник

QH

Quantum Harmonizer in KotlinLangRu
Иван Макеев
ок, если и  Брюс Эккель не прав, то каким образом вызывается механизм встраивания в Java?
Это не специфицировано. JVM может делать это как угодно, если это не ломает семантику кода.
источник

MG

Mikhail Guryev in KotlinLangRu
где найти инфу о том, как extensions в котлине переводятся в JVM?
источник

QH

Quantum Harmonizer in KotlinLangRu
Mikhail Guryev
где найти инфу о том, как extensions в котлине переводятся в JVM?
источник

MG

Mikhail Guryev in KotlinLangRu
не хочу язвить. здесь я был и читал стандартную доку по экстеншенам
источник