В Котлине чуть побольше.

итак нулейбл примитив = непримитив = проблемы с гц?

Ты только это здесь увидел?

то есть засовывание чего угодно в хип = проблема ЯП?

К слову про нуллейбл примитив в доке сказано https://kotlinlang.org/docs/reference/basic-types.html#representation, так что тут все очень даже явно

то есть засовывание чего угодно в хип = проблема ЯП?

неявное засовывание

и за этим нужно знать что такое гц

К слову про нуллейбл примитив в доке сказано https://kotlinlang.org/docs/reference/basic-types.html#representation, так что тут все очень даже явно

вот + тем, кто её читает.)

Я написал кучу примеров, когда неявно объекты создаются.

Напишите forEarch {} в загруженном месте и будут вам проблемы с GC

3 кажется

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

Ну тут опять к слову в джаве for (Item item: items) тоже создаст итератор..

Утечек в Котлине нет

Это язык

Ну тут опять к слову в джаве for (Item item: items) тоже создаст итератор..

Только людей, которые про это знают в джаве, намного больше, чем тех, кто про это знает в Котлине.

Почему-то.

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

Вот кстати, анонимные классы в Котлине, насколько я заметил, захватывают скоуп только тогда, когда это действительно нужно.

Все думают на лямбду.

Они очень хорошо сделали анонимки, да.

Только людей, которые про это знают в джаве, намного больше, чем тех, кто про это знает в Котлине.

котлин в основном популярен в андроид движе. а в андроид движе в принципе джаву хуже знают

Это правда.

Но по моей статистике на этот вопрос Котлинисты хуже джавистов отвечают.

На всякий случай ещё: больше строковых констант = больше GC root'ов

На вопрос про неявное создание объектов?

И более загруженный хип

На вопрос про неявное создание объектов?

Конкретно про итератор

Понял

Джависты тоже молодцы, пихают числа в мапу не думая

Утечек в Котлине нет

ну это же популярная штука, что если лямбда живёт дольше объекта в котором создалась то будут проблемы и думал неявные места про которые ты говорил будут let run apply и что-нибудь такое проперти мб

Но там чаще вспоминают про итератор

Автобоксинг в котлине не проблема. За счет инлайна в коллекциях его там вообще можно избежать, в остальном все как в джаве. Поэтому в целом даже лучше.

Джависты тоже молодцы, пихают числа в мапу не думая

Думая, Trove же :)

Ну это уже твой косяк, не языка

Автобоксинг в котлине не проблема. За счет инлайна в коллекциях его там вообще можно избежать, в остальном все как в джаве. Поэтому в целом даже лучше.

Лямбды одно из немногих мест, где Котлин быстрее.

Автобоксинг в котлине не проблема. За счет инлайна в коллекциях его там вообще можно избежать, в остальном все как в джаве. Поэтому в целом даже лучше.

Что? Как инлайн помогает избежать боксинга в коллекциях?

Он про простые лямбды

Которые не держатся рефами

На всякий случай ещё: больше строковых констант = больше GC root'ов

они же не руты. это просто массив и гц не начинает оттуда поиск

Начинает

В некоторых реализациях

Лямбды одно из немногих мест, где Котлин быстрее.

В остальных случаях Котлин либо медленнее, либо такой же

Начинает

Где можно почитать о GC рутах? У меня слишком приблизительное представление об этом.

У нас ребята исследовали на разных машинах, исходники смотрели.

Так-то GC очень слабо анализу поддается.

чтобы начинать поиск нужно знать заранее что это ссылка

Строка не ссылка?

Что? Как инлайн помогает избежать боксинга в коллекциях?

Дженериков не будет вообще. Поэтому и каста из Integer в int нет, там сразу примитив будет.

Ладно, ребята. Злые вы, критику вообще не умеете воспринимать, сразу троллите.

Как почти все котлинисты.

Дженериков не будет вообще. Поэтому и каста из Integer в int нет, там сразу примитив будет.

Где дженериков не будет? В коллекциях? Каста int->Integer и наоборот быть не может, это несовместимые типы.

Разочаровали меня.

Ладно, ребята. Злые вы, критику вообще не умеете воспринимать, сразу троллите.

чел нет

не надо так

ты писал

кококотлин

как ребёнок

У меня рука дрогнула в метро, в давке.

здесь тебе нормально отвечали

Случайно вышло.

это глупо

Не нормально :(

Даже места с генерацией объектов вы как холивар восприняли :(

Где дженериков не будет? В коллекциях? Каста int->Integer и наоборот быть не может, это несовместимые типы.

val intArr = intArrayOf(1, 2, 3) println(intArr.fold(0, { acc, cur -> acc + cur }))

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

Какое неуютное у вас коммьюнити.

оох

ERROR: S client not available

Пойду погрущу.

короче

welcome to python flood community! Мы говорим обо всем, кроме питона! За котлин позатирать можно =)

val intArr = intArrayOf(1, 2, 3) println(intArr.fold(0, { acc, cur -> acc + cur }))

intArray — не коллекция.

я бы поиследовал искодники гц

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

У меня рука дрогнула в метро, в давке.

2 раза дрогнула ;)

чтобы был интерес

intArray — не коллекция.

Ну массив. Операторы все теже, что и со списками.

2 раза дрогнула ;)

Была очень сильная давка!?

В Лондоне постоянно такое

Была очень сильная давка!?

в твоём кругу общения видимо твои шутки заходят

но жаль для этого алоцировать объект каждый раз

Кстати, а зачем там объект вообще? т.е. если так хочется использовать функцию, то чем не подходит такой вариант? inline fun <T1, T2, R> unwrap(t1: T1?, t2: T2?, action: (T1, T2) -> R): R? { if (t1 != null && t2 != null) { return action(t1, t2) } return null } inline infix fun Any?.otherwise(crossinline action: () -> Unit) { if (this == null) action() }

crossinline здесь не нужен

эт да, лишнее

Кстати, а зачем там объект вообще? т.е. если так хочется использовать функцию, то чем не подходит такой вариант? inline fun <T1, T2, R> unwrap(t1: T1?, t2: T2?, action: (T1, T2) -> R): R? { if (t1 != null && t2 != null) { return action(t1, t2) } return null } inline infix fun Any?.otherwise(crossinline action: () -> Unit) { if (this == null) action() }

я могу только догадываться зачем. предполагаю, что для того, чтобы не создавать лишний апи для всех типов. т.е. сделать это "ключевое слово"/метод применимым только в нужном контексте аля else

но предложенный тобой вариант тоже хорош

а нельзя сделать экстеншн функцию только для null? тогда otherwize по сути заменит элвис оператор

=)

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

а вообще, почитал тред на kotlin discuss который выше кидали и не понял, почему никто не предлагает вариант как в Swift

if (let localA = a, let localB = b) { } else {}

ну или что-то такое

по моему очень простое, удобное и неломающее ничего решение

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

красота

Кто libgdx использует с kotlin

Опишите ваши ощущения

@angmarr

Я использовал как-то. Вроде ок, но на пару неочевидных вещей я натыкался, что они мне пару часов отнимали.