i have this arrayList [{ "aaa": "#FF7B5CC1", "bbb": "000", "ccc": "ghffh" }] val arrayList = Arrays.asList<MyModel>(newitem) I want to replace a value inside it like replace "aaa": "#FF7B5CC1", to "aaa": "#000000" Dima let say i have `data class Mymodel(val aaa:String, val bbb:String,val ccc:String) in my class i have val arrayList = Arrays.asList<MyModel>(newitem) how can i replace the value inside it ?

i have this arrayList [{ "aaa": "#FF7B5CC1", "bbb": "000", "ccc": "ghffh" }] val arrayList = Arrays.asList<MyModel>(newitem) I want to replace a value inside it like replace "aaa": "#FF7B5CC1", to "aaa": "#000000" Dima let say i have `data class Mymodel(val aaa:String, val bbb:String,val ccc:String) in my class i have val arrayList = Arrays.asList<MyModel>(newitem) how can i replace the value inside it ?

arrayList.forEach { if (it.aaa == "#...") it.aaa = "#..." }

i have this arrayList [{ "aaa": "#FF7B5CC1", "bbb": "000", "ccc": "ghffh" }] val arrayList = Arrays.asList<MyModel>(newitem) I want to replace a value inside it like replace "aaa": "#FF7B5CC1", to "aaa": "#000000" Dima let say i have `data class Mymodel(val aaa:String, val bbb:String,val ccc:String) in my class i have val arrayList = Arrays.asList<MyModel>(newitem) how can i replace the value inside it ?

Look like you have the wrong data structure. List only contains items but doesnt use keys and gives access by index, so you have to iterate through list, find entry and change its property.

Look like you have the wrong data structure. List only contains items but doesnt use keys and gives access by index, so you have to iterate through list, find entry and change its property.

Actually it's a list of maps which are, probably, mapped to a data class

Actually it's a list of maps which are, probably, mapped to a data class

correct it map to a data class

слушайие, а в котлине extention функции - это же чисто синтаксический сахар? Т.е. полиморфизм работать не будет?

Не будет.

слушайие, а в котлине extention функции - это же чисто синтаксический сахар? Т.е. полиморфизм работать не будет?

Хм, а как ты хотел?

Хм, а как ты хотел?

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

Ну я не знаю, может ты хочешь что-то типа ext-interface. Что может быть когда-нибудь завезут в виде тайп-классов.

не, у меня последнее время очень часто встаёт вопрос диспатчинга. Например приходит из сети байты, ты их десериализуешь в Object/Serializable, а дальше тебе нужно запихнуть в обработчики типа onEvent(MySuperClass my) {...}

ну и один из способов который боле-менее выглядит красивым - это на Object повесить дефолтную реализацию onEvent которая, например, просто логирует и на каждый нужный объект ставим нужную нам реализацию и после десериализации вызываем obj.onEvent()

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

не, у меня последнее время очень часто встаёт вопрос диспатчинга. Например приходит из сети байты, ты их десериализуешь в Object/Serializable, а дальше тебе нужно запихнуть в обработчики типа onEvent(MySuperClass my) {...}

А чем ты десериализуешь байты в Object/Serializable?

А чем ты десериализуешь байты в Object/Serializable?

нуууу, в общем-то не суть, почти у любого сериализатора апи что-то вроде byte[] serialize(Serializable var1); Serializable deserialize(byte[] var1);

сорян за джавовый интерфейс

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

ну понятно что можно это сделать на мапе или на паттер-матчинге

но это какая-то простыня же будет, а с экстеншином элегантно )

можно использовать sealed

в будущем тебе внутри поле сделают интовое, и просто будет tableswitch

ну всё-равно, например 10 классов на 5 написаны свои имплементации onEvent, остальные подефолту, то что я предлагаю - это взял написал 6ую и всё работает, а со свичом - написал 6ую и пошёл в мапу/switch и добавил вызов

в эвент дривене, события часто появляются новые

В интерфейс закинуть дефолтную имплементацию?

ну не в сам интерфейс, а тоже экстеншином

ну вообще чем плох when с его default case?

я же написал, добавление в 2 места

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

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

у тебя очень быстро меняются требования

в общем, я не говорю что задача не решаема, но идеала пока нет

в смысле? требование одно - писать новый код, не изменяя старый

Ребята, как я могу проверить, что данная переменная ТОЧНО содержит "session_secret"? val sessionSecret = remoteMessage?.data?.get("session_secret")

это же такой клёвый идеал ооп к которому нужно стремиться

А expression-problem разве решена в ооп?

в смысле? требование одно - писать новый код, не изменяя старый

Ну вот смотри

sealed class Event class AddEvent : Event() class RemoveEvent : Event() fun Event.handle() { when (this) { is AddEvent -> println("Let's Add") is RemoveEvent -> println("Let's Remove") else -> println("Unknown type ${this::class}") } }

это же такой клёвый идеал ооп к которому нужно стремиться

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

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

Редактировать нужно только тело when

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

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

только не все сразу)

Редактировать нужно только тело when

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

Окей, значит делаешь интерфейс и погнал.

В чем проблема?

sealed class Event class AddEvent : Event() class RemoveEvent : Event() fun Event.handle() { when (this) { is AddEvent -> println("Let's Add") is RemoveEvent -> println("Let's Remove") else -> println("Unknown type ${this::class}") } }

конкретно тут всё-равно есть возможность написать функцию и забыть её прописать в этом свиче и новая фукнциональность не фурычит

Окей, значит делаешь интерфейс и погнал.

какой интерфейс?

ну для всех твоих ивентов

и?

допустим есть

даже допустим там дефолтная реализация лежит

вот для Вашего случая: sealed class Event class IntEvent(val i: Int) : Event() class StirngEvent(val str: String) : Event() и далее Вам нужно раскидать это до методов fun onEvent(val ie: IntEvent) { ie.i + ie.i } fun onEvent(val se: StringEvent) { print(se.str) }

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

мне кажется есть только два варианта: 1) находить тип десериализованного объекта и через рефлекшн вызывать нужный onEvent 2) придумать что-то с генерацией кода по аннотациям

без сфитча, без мапы и т.п.

даже допустим там дефолтная реализация лежит

interface Event { fun handle() = println(this::class) } class AddEvent : Event { override fun handle() = println("Add") } class RemoveEvent : Event { override fun handle() = println("Remove") } class EditEvent : Event {}

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

мне кажется есть только два варианта: 1) находить тип десериализованного объекта и через рефлекшн вызывать нужный onEvent 2) придумать что-то с генерацией кода по аннотациям

это всё понятно, это очевидные варианты, в целом, мапа в этом плане выглядит самым лучшим выходом

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

дааа, спасибо

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

ну я умею в полиморфизм, я не думал что Вы обо мне так плохо подумаете =)

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

события по определению - value type

т.е. возвращают только данные

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

Иначе бы просто полиморфизм

попробуй с генерацией кода, вроде довольно просто такого достичь

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

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

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

Почему бы не sealed использовать? Добавил новый тип - у всех билд сломался пока не добавят обработчик

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

ну в целом так сейчас и делаю, только на джавке

и через динамическую генерацию байткода

Почему бы не sealed использовать? Добавил новый тип - у всех билд сломался пока не добавят обработчик

так нет же, если else есть, то ничего не сломается

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

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

тогда тут опять противоречие

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

ну без else нельзя, событий сотни, а конкретный сервис юзает 10

ну и да, со свичом всё-равно менять код сервиса в более 2х местах

почему?

в смысле просто в 2х местах

одно место - тело when, а второе место?

сама обработка

важна-то сама обработка, всё остальное бойлерплейт

свитч - бойлерплейт

эм, ну это странно. обработка это вызов метода из when?

мапа обработка - это функция fun onEvent(val ie: IntEvent) { ie.i + ie.i }

почему не делать обработку прям в when?

не вижу в общем тут проблемы

почему не делать обработку прям в when?

каша получится

если б все в одну строчку, то да

ну если не в одну - вызвал метод и все. я бы не сказал это это два места

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

почему не делать обработку прям в when?

Однородность лучше, то есть если есть when с вызовами в нескольких ветках разных методов, ИМХО, лучше и все остальное по методам накидать.

короче это всё-равно получается огромная простыня со switch где в каждом сервисе одно и тоже fun dispatch(val event: Event) { when (event) { is AddEvent -> onEvent(event) is RemoveEvent -> onEvent(event) is IntEvent -> onEvent(event) is StringEvent -> onEvent(event) {... и ещё вагон аналогичных вызовов ... } else -> println("Unknown type ${this::class}") }

Визитор может?

омг, визитор подразумевает код в Event

Нет, сча накидаю что я имею в виду)

дабл визитор?