Привет, подскажите как сделать так ? private var colorMap = IntArray(ROWS, { IntArray(COLUMNS, { 0 }) }) двумерный интовый массив нулей

Опять же одномерные массивы предпочтительны

Опять же одномерные массивы предпочтительны

если таблица: rows,columns. как я ее в одномерный запихаю)

?

если таблица: rows,columns. как я ее в одномерный запихаю)

index = x + rows*y, например

короче, матрицу же можно разложить в линию

index = x + rows*y, например

чет геморно )

Ну многомерные массивы в си, например, моделируются через одномерные, и сделано это, для перфоманса

в таблице типа путь искать по похожим ячейкам... там ад будет

Обернуть массив и написать нужный get не вариант типо?

RichArray(w: Int, h: Int) { val arr: IntArray = IntArra(w * h) fun get(x: Int, y: Int) ... }

Обернуть массив и написать нужный get не вариант типо?

а чем двумерный тут будет хуже ?

Если перфоманс не нужен, то впринципе пофигу

RichArray(w: Int, h: Int) { val arr: IntArray = IntArra(w * h) fun get(x: Int, y: Int) ... }

даже можно так: operator fun get(x: Int, y: Int)

и потом val r = RichArray(10,10) r[1,1]

В соседнем чатике действует недельный запрет на флуд, так что вброшу здесь. Моя внутренняя Ванга вангует в ближайшем будущем пачку языков, транслирующихся в гошечку, как тебе такое -Илон Маск- Андрей Бреслав?

и потом val r = RichArray(10,10) r[1,1]

а это не медленне ? процессорное время всмысле

медленнее чего?)

а это не медленне ? процессорное время всмысле

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

А если это будут разные массивы, они будут разбросаны по хипу

медленнее чего?)

Array(10, {IntArray(10,{0})})

Array(10, {IntArray(10,{0})})

так не сделаешь)

А если это будут разные массивы, они будут разбросаны по хипу

я не сильно догоняю, но какая разница с какой части памяти брать - главное как это делать наврерное ?

я не сильно догоняю, но какая разница с какой части памяти брать - главное как это делать наврерное ?

https://en.wikipedia.org/wiki/Locality_of_reference

Array(10, {intArrayOf(0))}) ну или там как то )) типа того

я не сильно догоняю, но какая разница с какой части памяти брать - главное как это делать наврерное ?

это про архитектуру памяти вобщем

так не сделаешь)

Array(ROWS, { IntArray(COLUMNS, { 0 }) }) - все работает = заполняет нулями двумерный

это про архитектуру памяти вобщем

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

я не могу в Kotlin сделать так ? fun <T : BaseViewModel> create(): T { return SplashViewModel() } Пишет ошибку, что требует чтобы я в методе отдавал T, но я вроде и отдаю T, т.к. Т наследуются от BaseViewModel и SplashViewModel тоже.. что не так (

я не могу в Kotlin сделать так ? fun <T : BaseViewModel> create(): T { return SplashViewModel() } Пишет ошибку, что требует чтобы я в методе отдавал T, но я вроде и отдаю T, т.к. Т наследуются от BaseViewModel и SplashViewModel тоже.. что не так (

Постоянно путаю, но попробуйте fun <out T : BaseViewModel>

Постоянно путаю, но попробуйте fun <out T : BaseViewModel>

не помогает, пишет что out можно только для аннотации классов юзать, а если в класс выношу ошибка та же остается

мне кажется или так сделать нельзя просто, или я что-то не так написал в методе

не помогает, пишет что out можно только для аннотации классов юзать, а если в класс выношу ошибка та же остается

Щас сяду за комп, попробую

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

можно ли вот вопрос

я не могу в Kotlin сделать так ? fun <T : BaseViewModel> create(): T { return SplashViewModel() } Пишет ошибку, что требует чтобы я в методе отдавал T, но я вроде и отдаю T, т.к. Т наследуются от BaseViewModel и SplashViewModel тоже.. что не так (

А мб просто fun create(): BaseViewModel = SplashViewModel()

так прокатит

но на выходе я буду иметь BaseViewModel

и нужно будет юзать каст

что неочень, собственно для этого и дженерики существуют

только вот не факт что в котлин так можно

А как вы вызываете метод-то? Вы ж обещаете вернуть T, а возвращаете SplashViewModel.

а разве не так и нужно ?

оно должно понять что T наследуется от BaseViewModel

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

Да нет, внутри метода вы должны отдать T или его наследника.

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

ну так в java работает

Да нет, внутри метода вы должны отдать T или его наследника.

а как тогда исправить

чтобы был метод который отдает разные ViewModel наследуемые от одной

и на выходе не нужно юзать каст уже

а сразу нужный тип будет

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

я не могу в Kotlin сделать так ? fun <T : BaseViewModel> create(): T { return SplashViewModel() } Пишет ошибку, что требует чтобы я в методе отдавал T, но я вроде и отдаю T, т.к. Т наследуются от BaseViewModel и SplashViewModel тоже.. что не так (

В данном случае вы обещаете вернуть T, а пытаетесь вернуть SplashViewModel. Так не прокатит

Вы-то при вызове укажете, что вы вместо <T> конкретное хотите, но тело метода это игнорирует.

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

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

есть такая возможность ?

ну как я понимаю вопрос в том как сделать у метода возвращаемый тип == наследники BaseViewModel

любые, никакой конкретики

есть такая возможность ?

Есть, если это не противоречит типизации

для этого ж и нужны дженерики

Суть с сигнатурой вы правильно уловили, fun <T: Base> method(): T, а вот с телом метода пока не очень. return Derived не сработает, ибо Derived в общем случае не наследник T.

Есть, если это не противоречит типизации

а как

as T и не парься

Трудно дать более конкретный совет, ибо пока не ясно, как этот метод опирается на переданное снаружи T.

а как

Просто надо возвращать тип, который заявлен в функции

А то как в том анекдоте, что ищу не там где потерял, а там где светло

блин, значит я не умею объяснять

Ох вей

У вас просто упрощённый пример оказался слишком упрощённым. Поясните суть вашего create, как он использует на деле T.

блин, значит я не умею объяснять

Я щас потыкал-потыкал, но ничего не нашёл. Скорее всего нельзя.

У вас просто упрощённый пример оказался слишком упрощённым. Поясните суть вашего create, как он использует на деле T.

Вот да

Если т сделать рефайд и потом т::класс.ньюинстанс, то будет норм

val viewModel = ViewModelProvider.create<SplashViewModel>(SplashViewModel::class.java)

к примеру так

и viewModel : SplashViewModel

не BaseViewModel

для других viewModel аналогично

ну для всех в принципе )

внутри метода будет when который будет смотреть входной типо и создавать объект и отдавать

inline fun <reified T:Any> create(): T = T::class.java.newInstance() вот такой код будет работать

в идеале если бы он мог вообще сразу на T смотреть

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

Если вы вяжитесь на JVM, то внутри <reified T: BaseViewModel> и return T::class.newInstance(), как выше верно подсказали, а по уму он должен иметь фабрики этих ваших наследников от BaseViewModel.

есть подводные камни, но по-другому к Т доступа в рантайме не получить

Можно просто явно параметром в метод передавать KClass<T>, тогда inline не нужен.

val viewModel = ViewModelProvider.create<SplashViewModel>(SplashViewModel::class.java)

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

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

ну если так рассуждать любое создание объекта в каком-то смысле извращенный способ вызвать конструтор )

но используются же фабрики и т.д. для создания объектов

а не просто конструторы дергаются у каждого и всё, внутри они же и дергаются, да

Правильно, фабрики позволяют убрать вызов конструктора в место, которое точно знает тип, а не использовать newInstance.

фабрики они абстрагируют обычно конкретный тип, а тут ты создашь именно тот Т который ты знаешь при вызове. Возможно там проще будет написать что-то типа val viewModel = ViewModelProvider.create<SplashViewModel>(SplashViewModel())

Правильно, фабрики позволяют убрать вызов конструктора в место, которое точно знает тип, а не использовать newInstance.

хм

Где-то в одном месте ставится соответствие KClass<X> -> способ создать объект типа X, а потом эти ваши методы вроде create обращаются к зарегистрированным фабрикам.

Щас накопал про Inline properties https://kotlinlang.org/docs/reference/inline-functions.html Это что вообще такое? (о.о)

Об этом, собсна, все эти даггеры и прочие.

Щас накопал про Inline properties https://kotlinlang.org/docs/reference/inline-functions.html Это что вообще такое? (о.о)

Дык это проперти, которые без backing field.

Где-то в одном месте ставится соответствие KClass<X> -> способ создать объект типа X, а потом эти ваши методы вроде create обращаются к зарегистрированным фабрикам.

вот это интересное решение

Т.е. сахарок над методами get и set. Почему бы их и не инлайнить при надобности.

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