Котлин уже сто лет как on par с джавой, в некоторых местах её даже немного обгоняя, если использовать с умом. В случае с LibGDX проще потерять производительность, если писать неэффективный код (ну, там, не использовать пулы и всё такое прочее).

просто в котлине кооллекции взяты с джавы, а в либе они переделаны спецом под ведроид, тогда стоит юзать массивы либы ?

ясно, спасибо за ответы.

Котлин уже сто лет как on par с джавой, в некоторых местах её даже немного обгоняя, если использовать с умом. В случае с LibGDX проще потерять производительность, если писать неэффективный код (ну, там, не использовать пулы и всё такое прочее).

а эффективно использовать пулы на 300-500 объектов четырех, шести типов ?

а эффективно использовать пулы на 300-500 объектов четырех, шести типов ?

Чувак, зачем гадать. Есть же профайлеры и для десктопа и для android.

просто в котлине кооллекции взяты с джавы, а в либе они переделаны спецом под ведроид, тогда стоит юзать массивы либы ?

они не под ведроид переделаны, а под минимальное использование памяти

ну да

ну для ведроида это +

это вообще для игр маст хэв

Я бенчмарки не делал, так что конкретного ничего не подскажу. Да и игру я забросил задолго до момента, когда эту самую производительность можно было бы щупать на разных девайсах. Присоединяюсь к совету о профайлерах -- в коде ж быстро меняется, использовать или не использовать пул, если я правильно помню.

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

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

Пул делает за вас ровно то же самое. Так что если вы сделали за него его работу, то он вам не особо поможет ;)

А в чем кайф null в котлине ? Я подумал что если я помечу "?" то кусок этого кода просто проигнорится и не будет вызван или он его даже не скомпилирует ? Если не скомпилирует, но null потом заменится на объект, и как бэ ничего и не будет

код то не скомпилен

вообщем пробовал, у меня идея все белым помечала... что то не пахало ))) юзал !! всякие там )

В Kotlin кайф не от null, а от того, что можно в конкретном куске кода гарантировать его отсутствие. Забудьте о !!, этот оператор превращает волшебный Kotlin в б-гомерзкую Java.

Пробегитесь по Kotlin Koans, если этого ещё не делали -- частично придёт просветление.

так а что это

так а что это

nullable — это бесплатный optional

нашел

Что "это"? !! -- это способ превратить T? и T, попутно отстрелив себе ногу, когда там будет null.

ну смотрите, у меня есть var я оюъявляю его "?" и присваиваю null, этот вар где то в коде юзаетсяпроверить на != null я так и не смог) и вот я думал что если у меня вар = null то этот кусок кода проигнорится, и когда он уже не будет null то будет работать, Это не так ?

в процессе выполнения программы

> проверить на != null я так и не смог надо код

пробники были , не помню уже что я там писал ((

суть не в этом..

ну смотрите, у меня есть var я оюъявляю его "?" и присваиваю null, этот вар где то в коде юзаетсяпроверить на != null я так и не смог) и вот я думал что если у меня вар = null то этот кусок кода проигнорится, и когда он уже не будет null то будет работать, Это не так ?

не очень внятная постановка вопроса если у тебя есть что-то типа: var x: Int? = null ... if (x == null) { // ... } else { // <-- здесь x автоматически скастуется к Int (не nullable) и дополнительно его приводить не надо }

правильно ли я понял работу null

var x: Int? x?.let { // it -- это Int }

А вообще Котлин дисциплинирует и учит любить val

(это как final в джаве)

не очень внятная постановка вопроса если у тебя есть что-то типа: var x: Int? = null ... if (x == null) { // ... } else { // <-- здесь x автоматически скастуется к Int (не nullable) и дополнительно его приводить не надо }

Не скастуется, на то и жалоба ж наверняка.

не очень внятная постановка вопроса если у тебя есть что-то типа: var x: Int? = null ... if (x == null) { // ... } else { // <-- здесь x автоматически скастуется к Int (не nullable) и дополнительно его приводить не надо }

чет не понял тогда в чем отличие от жабы ? вроде все тоже самое, только еще лишний знак вопроса

А зачем функциональщикам котлин, если есть скала? В чем интерес?

Не скастуется, на то и жалоба ж наверняка.

как не скастуется, если скастуется?

скалу я не знаю и даже не видел )) увидел котлин - понравлся )

Все-таки котлин более наследует ООП стиль от джавы, или я не прав?

как не скастуется, если скастуется?

я могу вызывать методы без ? и всё будет ок как раз благодаря смарткасту

А зачем функциональщикам котлин, если есть скала? В чем интерес?

Легковесный stdlib, маленький оверхед, удобный интероп с джавкой. Но я не скалист, я не отвечаю за слова.

чет не понял тогда в чем отличие от жабы ? вроде все тоже самое, только еще лишний знак вопроса

котлин не позволит неявно сделать NPE

Ну котлин проще скалы Плюс встроенный транслятор с джавы в котлин

А зачем функциональщикам котлин, если есть скала? В чем интерес?

в котлине нет тех печалек, которые есть в скале — implicit conversions, traits, tuples, прочих невменяшек

как не скастуется, если скастуется?

Если это проперти, а не локальная переменная, то не скастуется из-за возможности обнулить это проперти в другом потоке после проверки, но перед использованием.

Но вы пишите на котлине прям в функциональном стиле?

Плюс куча практик была перенесена в котлин из джавы, чтобы сделать побольше сахара

Но вы пишите на котлине прям в функциональном стиле?

ну я смешиваю с ООП

в котлине нет тех печалек, которые есть в скале — implicit conversions, traits, tuples, прочих невменяшек

А в чем собственно неменяемость тупплов?

в смешанном скорее всего

чет не понял тогда в чем отличие от жабы ? вроде все тоже самое, только еще лишний знак вопроса

смотри, смарткаст Int? в Int произойдёт только если выше была проверка на null, как в примере

Я вот чуть пробовал хаскель, но до меня не дошло как можно смешать фунциональщину и ооп

А в чем собственно неменяемость тупплов?

Элементы не именованы, это неявно. В котлине их попробовали и осознанно отказались.

Если это проперти, а не локальная переменная, то не скастуется из-за возможности обнулить это проперти в другом потоке после проверки, но перед использованием.

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

да нету уже примеров )) я просто вопросы задаю

и читаю ответы

https://kotlinlang.org/docs/reference/typecasts.html

во блин, а ведь я это читал , память дырявая ((((

смотрел*

всем спасиб за ответы, пойду дальше голову ломать )

Ещё раз: если в функции есть переменная типа Int?, то после проверки её на null она стайпкастится до Int. Если речь о nullable var проперти, то тайпкаст после проверки не сработает, и предупреждение в IDE вполне себе хорошо объясняет, почему, просто над этим предупреждением надо один раз посидеть и вдумчиво его прочитать. После этого станет понятно, что с этим делать ;)

в котлине нет тех печалек, которые есть в скале — implicit conversions, traits, tuples, прочих невменяшек

Ну такое, там есть вещи пострашенее - типа макросов и времени компиляции

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

Ты ж наверняка не хуже меня знаешь, что об это спотыкается каждый первый начинающий :)

всем спасиб за ответы, пойду дальше голову ломать )

вот тут ещё можно поподробнее именно про работу с нуллаблами прочитать: https://stackoverflow.com/questions/34498562/in-kotlin-what-is-the-idiomatic-way-to-deal-with-nullable-values-referencing-o#34498563

в котлине нет тех печалек, которые есть в скале — implicit conversions, traits, tuples, прочих невменяшек

а с трейтами что не так? (никогда на скале не писал)

Я вот чуть пробовал хаскель, но до меня не дошло как можно смешать фунциональщину и ооп

Ну смотри, есть же коллекции и всякие операторы (map/flatMap) на них - чем не “локальный” ФП внутри ООП Лично я то не мешаю - пишу все на функциях внутри object

а с трейтами что не так? (никогда на скале не писал)

Как HKT доедут до котлина, так сразу и узнаем :)

Как HKT доедут до котлина, так сразу и узнаем :)

Ну HKT наверное не доедут, а тайпклассы надеюсь доедут)

Ну такое, там есть вещи пострашенее - типа макросов и времени компиляции

Спасибо, буду знать) Всё, что я знаю о Скале — понаслышке.

а с трейтами что не так? (никогда на скале не писал)

Они не нужны, их вообще не должно было существовать.

Пахнет холиваром, пойду схожу за попкорном.

Они не нужны, их вообще не должно было существовать.

ну я не знаю конкретно как в скале, но вообще трейты конечно же нужны)

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

они всё отлично сделали.

https://kotlinlang.org/docs/reference/basic-syntax.html

ну я не знаю конкретно как в скале, но вообще трейты конечно же нужны)

Зачем тупое копирование процедуры из одного места в другое, если есть объекты?

Ты примешиваешь себе какое-то поведение, а мог бы агреггировать объект (или несколько), реализующий это поведение.

Примешивать же можно и к классам, которыми ты не управляешь -- насколько я понимаю, в этом их основная прелесть. Ну и аггрегировать придётся ручками, ибо вроде как делегировать нескольким объектам одновременно нельзя.

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

хм, я посмотрел на трейты в scala в этом действительно мало смысла

Примешивать же можно и к классам, которыми ты не управляешь -- насколько я понимаю, в этом их основная прелесть. Ну и аггрегировать придётся ручками, ибо вроде как делегировать нескольким объектам одновременно нельзя.

а, так всё-таки можно к сторонним классам примешивать? из примеров которые я сейчас смотрел это не видно, надо ещё почитать

Примешивать же можно и к классам, которыми ты не управляешь -- насколько я понимаю, в этом их основная прелесть. Ну и аггрегировать придётся ручками, ибо вроде как делегировать нескольким объектам одновременно нельзя.

Примешивать к чужим классам — это implicit class, не? То, что у нас называется extension function. В котлине можно делегировать реализацию интерфейса объекту.

а, так всё-таки можно к сторонним классам примешивать? из примеров которые я сейчас смотрел это не видно, надо ещё почитать

Я ж говорю, я мимокрокодил и скалу не тыкал. В расте вроде можно, в го точно можно, в скале -- не знаю.

Я ж говорю, я мимокрокодил и скалу не тыкал. В расте вроде можно, в го точно можно, в скале -- не знаю.

ну вот я тоже сужу по трейтам в Rust, а скалу не трогал)

Примешивать к чужим классам — это implicit class, не? То, что у нас называется extension function. В котлине можно делегировать реализацию интерфейса объекту.

Это одну функцию и (что самое неудобное) без состояния.

ну вот я тоже сужу по трейтам в Rust, а скалу не трогал)

в Rust нет ООП, думаю, в этом дело

Это одну функцию и (что самое неудобное) без состояния.

охх, какие костыли нужны, чтобы состояние примешать. Композиция лучше

Примешивать к чужим классам — это implicit class, не? То, что у нас называется extension function. В котлине можно делегировать реализацию интерфейса объекту.

ну не, extension function это отдельная функция, а трейт - это целостный интерфейс

Примешивать к чужим классам — это implicit class, не? То, что у нас называется extension function. В котлине можно делегировать реализацию интерфейса объекту.

Одному объекту и по-моему без переопределения методов, как я отметил выше. Могу ошибаться.

состояние не надо примешивать, фу

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

в Rust нет ООП, думаю, в этом дело

ну наследование, инкапсуляция и полиморфизм есть, а то что "классического" Java-like наследования нет - так и слава богу

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

хмм, а как это делается? (я бы сделал композицией)

В сравнении с Го в Расте вполне себе есть ООП :D

ну наследование, инкапсуляция и полиморфизм есть, а то что "классического" Java-like наследования нет - так и слава богу

Там есть интерфейсы? Или как это сделано? (сужу о расте по статье в Вики)

хмм, а как это делается? (я бы сделал композицией)

https://docs.scala-lang.org/tour/traits.html Да собственно как-то так.

Там есть интерфейсы? Или как это сделано? (сужу о расте по статье в Вики)

там трейты, они помощнее интерфейсов

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

https://docs.scala-lang.org/tour/traits.html Да собственно как-то так.

выглядит как интерфейс

там трейты, они помощнее интерфейсов

отличие в том что 1) реализация трейта отдельно от объявления структуры, поэтому как раз можно примешивать поведение к чужим структурам 2) можно объявлять статические методы в трейте