Господи, как же меня бесит IntArray и Array<Int> в Котлине... И ещё это сраное создание матрицы. Почему надо было изобретать велосипед?

мб потому что есть дестракчеринг и можно без многовмерного массива работать с матрицами?

ладно, матрицы ладно.. Но IntArray и Array<Int>...

ну джаве же есть ByteArray)

попутал. нету)

А как вы еще предлагаете различать массивы примитивных типов?

Зачем вообще было делать IntArray?

очередное творение из silicon valley)) https://dev.to/clarifai/not-kotdog-using-computer-vision-to-detect-hot-dogs-in-kotlin

Зачем вообще было делать IntArray?

джакодер правильно сказал

Примитивных типов мало, поэтому сделали для каждого.

Если вас больле устроит такой ответ

так Array<Int> нормально же. Хотчется Int[] ?

Нет. Не хочется. Просто не понимаю зачем идёт, по сути, дубляция

разница в том что Array<Int> и IntArray это разные массивы

первый массив Integer , второй int

тут много дубляции в котлин

Я так понимаю человеку не нравится отсутствие джавового синтаксиса)

Нет, мне спокойно и хорошо без Джава-синтаксиса.)

да кому вообще массивы нужны)

Ну мне.)

первый массив Integer , второй int

Спасибо.)

единственное что печалит это arrayOf вместо какого-нить { }

Ну, лично мне нормально.)

Зато ясно любому, кто не особо знаком с кодом на Джава и Котлине.)

первый массив Integer , второй int

а в чем разница? обертка вокруг примитива?

{} для анонимных функций же

Да

ну да

Integer.parseInt например

Могу ошибаться, но смысл такой

а в чем разница? обертка вокруг примитива?

да. первый это ссылочный тип-обертка для примитива

Единственная причина, по которой и Array<Int>, и IntArray существуют, заключается в том, что это разные типы.

...и они не взаимозаменяемы и не интероперабельны.

{} для анонимных функций же

в качестве литерала массива и [ ] подойдет

Зачем вам литералы для массивов? Кто-то часто использует массивы?

Зачем вам литералы для массивов? Кто-то часто использует массивы?

вот это поворот

ток для вараргов

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

и то только когда этого требует сторонние либы

Зачем вам литералы для массивов? Кто-то часто использует массивы?

Бедный, бедный GC

Я так понимаю, параметрический полиморфизм реализуется в Джаве и Котлине за счёт дженериков?

да

А полиморфизм приведения типов работает только с объектами и числами, да? Ну, типо должен прийти Int, пришёл float, и он автоматом привёл. Так?

в котлине надо руками приводить

toInt(), toFloat() и тд

Ок, тогда только с объектами? То есть должен прийти Parent, но пришёл Child, наследуемый от Parent, и он автоматом приводится к Parent. Да?

Я так понимаю, параметрический полиморфизм реализуется в Джаве и Котлине за счёт дженериков?

там не все так просто, почитай про затирание типов...

Тбдж

Бедный, бедный GC

Почему бедный и как это относится к литералам?

Ок, тогда только с объектами? То есть должен прийти Parent, но пришёл Child, наследуемый от Parent, и он автоматом приводится к Parent. Да?

Было бы неверно говорить, что Child *приводится* к Parent. Child *является* Parent.

Я так понимаю, параметрический полиморфизм реализуется в Джаве и Котлине за счёт дженериков?

А как ещё может реализовываться параметрический прлиформизм в нединамических языках?

Сборка объктов же, примитивные в стек кладутся, а кучу кто чистить будет?)

Сборка объктов же, примитивные в стек кладутся, а кучу кто чистить будет?)

Ну, примитивы и в куче обитают, в полях объектов. Так что я пока слабо понимаю, о чём это сообщение.

Поому что массивы примитивных в стеке лежат, и я считаю, что они нужны.

Насколько это плохой стиль использовать кучу вложенных it.use? Или лучше в var вынести, чтобы понятнее было? Там JDBC коннекшены, стейтменты и резалты something.use { it.use { it.use { } } }

Если логически можно, в функцию

Поому что массивы примитивных в стеке лежат, и я считаю, что они нужны.

На JVM массивы не лежат в стеке.

Пардон.

Можно прийти к выводу, что нужны массивы примитивов (IntArray etc), зачастую нужны списки (listOf("some object")), а вот массивы объектов не особо полезны.

Насколько это плохой стиль использовать кучу вложенных it.use? Или лучше в var вынести, чтобы понятнее было? Там JDBC коннекшены, стейтменты и резалты something.use { it.use { it.use { } } }

Ну если по другому никак - то ок

единственное, вложенные it - бэд практис

Ну если по другому никак - то ок

var connection = database.connection; connection.use { ... }

ERROR: S client not available

единственное, вложенные it - бэд практис

надо поправить тогда

Всем привет! А подскажите пожалуйста, можно ли каким то стат анализатором обнаружить в структуре андройд приложения классы и методы, которые могут существовать как internal/private, а ты их сделал пабликом по умолчанию, потому что не досмотрел? Никто такой проверки не заводил у себя?

Идея же постоянно подсказывает и ворнинги ставит

Поому что массивы примитивных в стеке лежат, и я считаю, что они нужны.

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

☠️ Umren ☠️ в обратную ошибку - если ты поставишь приват метод там, где нужен паблик. Я спрашиваю об обратном - анализируешь код и тебе идея говорит - чувак, тебе тут можно приват/интернал влепить

или не? Варнинги на интернал тоже приходят?

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

Почему в специальном месте?

Всмысле нужен паблик? Если твой паблик нигде не используется то зачем тон тебе?

или не? Варнинги на интернал тоже приходят?

Вроде нет, да и сложно это проверить будет, если проект многомодульный или вдруг у тебя либа. Надо было как в C# по умолчанию у классов сделать видимость internal ?. Лично я стараюсь явно ставить internal, а уже потом убираю если код не компилируется))

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

@angmarr тоже вариант

Почему в специальном месте?

вне поколений. по сути массивы единственный источник больших объёмов памяти и их не выгодно постоянно перемещать. поэтому обычно делают специальный загон для массивов где Mark-Sweep/Mark-Compact

вне поколений. по сути массивы единственный источник больших объёмов памяти и их не выгодно постоянно перемещать. поэтому обычно делают специальный загон для массивов где Mark-Sweep/Mark-Compact

Оо, интересно, где почитать можно?

gc handbook. делал бакалаврскую работу, но в общем сам сборщик так и не доделал из-за бесконечного числа багов. просто обзорная работа вышла

gc handbook. делал бакалаврскую работу, но в общем сам сборщик так и не доделал из-за бесконечного числа багов. просто обзорная работа вышла

Спасибо.

https://github.com/chewiebug/GCViewer вот такая вот есть штука, но она как бы не подтверждает мои слова, что кроме поколений и perm есть какое то ещё место в сборщике. можно в цикле посоздавать массивы разных размеров посмотреть что происходит

https://github.com/chewiebug/GCViewer вот такая вот есть штука, но она как бы не подтверждает мои слова, что кроме поколений и perm есть какое то ещё место в сборщике. можно в цикле посоздавать массивы разных размеров посмотреть что происходит

Классно, тоже гляну, спасибо.

gc handbook. делал бакалаврскую работу, но в общем сам сборщик так и не доделал из-за бесконечного числа багов. просто обзорная работа вышла

Спасибо

что. да хватит. не такое уж великое дело) вообще говоря это единственная книга, которую можно нагуглить, и она в принципе единственная по теме. дальше наверное только исходники смотреть. https://en.wikipedia.org/wiki/Jikes_RVM вот эта штука наверное более менее читаема, тк для ресерча создавалась

кто-то в котлине пишет так аннотации?

в одну строку

я, а в чем проблема??

интересно

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

а если несколько их

как оказалась это рекомендованый стайл

неудобно имхо когда несколько аннотаций

несколько?? например??

несколько?? например??

Возьми какой-нибудь Spring, где 3-4 аннотации - это норма.