подумал, что нет смысла в фолде: fun <T> List<T>.removeItAndNext(item: T): List<T> { var idxRemove = -1 return filterIndexed { index, it -> when (item) { it -> { idxRemove = index false } else -> !(index > -1 && index == idxRemove) } } }

> есть список и элемент из него

У нас список, а не Set.

подумал, что нет смысла в фолде: fun <T> List<T>.removeItAndNext(item: T): List<T> { var idxRemove = -1 return filterIndexed { index, it -> when (item) { it -> { idxRemove = index false } else -> !(index > -1 && index == idxRemove) } } }

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

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

в условии написано что есть элемент, а не индекс элемента

вопросы по условию к автору задачи :)

в условии написано что есть элемент, а не индекс элемента

Но чтобы указать на нужный нам элемент - нужно передать индекс.

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

Вроде должно норм отработать

А почему удаляем, передавая элемент, а не индекс элемента? Есть, у меня, к примеру, последовательность 0, 1, 2, 3, 2, 4. Я хочу удалить последние два элемента.

Кидаю 2 - удалятся 2 и 3, хотя я хочу 2 и 4.

Кидаю 2 - удалятся 2 и 3, хотя я хочу 2 и 4.

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

Но чтобы указать на нужный нам элемент - нужно передать индекс.

есть методы для поиска по элементу

val oldList = listOf(0, 1, 2, 3, 4, 5) val list = oldList.toMutableList() if (list.size > index) list.removeAt(index) if (list.size > index) list.removeAt(index)

val idx = list.indexOf(item) return list.subList(0, idx) + list.subList(idx + 2, list.size)

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

а стримы (сиквенс) тут не поможет ?

val idx = list.indexOf(item) return list.subList(0, idx) + list.subList(idx + 2, list.size)

моя первая реализация! ?

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

Ну это уже другой разговор

а стримы (сиквенс) тут не поможет ?

так один проход же, что толку от сиквенса

моя первая реализация! ?

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

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

да это число для фана, ищу красивое решение

очень простая задача, а вот такого вот решения простого, да еще чтобы в один проход чот не видно

Все же вроде в один проход, не?

только те что через фолд и последняя реализация через фильтрИндексед, остальные вроде нет

очень простая задача, а вот такого вот решения простого, да еще чтобы в один проход чот не видно

Решений простых очень много, а вы, как я вижу, хотите ещё и желательно в одну строчку. :)

только те что через фолд и последняя реализация через фильтрИндексед, остальные вроде нет

и саблисты в один, и removeAt

а, removeAt два раза скопирует хвост

а может заюзать линкед? фигня конечно, но можно найти элемент и есть доступ к следущему

а может заюзать линкед? фигня конечно, но можно найти элемент и есть доступ к следущему

зачем? О_о

линкедлисты не нужны

линкедлисты не нужны

очень редко всетаки нужны

зачем? О_о

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

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

И всё это ценой кучи узлов листа в хипе и постоянных cache miss'ов.

И всё это ценой кучи узлов листа в хипе и постоянных cache miss'ов.

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

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

Все хорошо, тут. Но потом ты захочешь проитерироваться по листу и вся эта микрооптимизация накроется

И всё это ценой кучи узлов листа в хипе и постоянных cache miss'ов.

так то ч не спорю

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

но это же сферическое решение в вакууме, на практике у нас нет доступа к узлам

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

так это же лишнее копирование

а мы хотели в один обход вроде

так это же лишнее копирование

где?

но это же сферическое решение в вакууме, на практике у нас нет доступа к узлам

написать свое) я прсото предложил

ну, в линкед лист запихать элементы

так это же лишнее копирование

ты ничего не копируешь просто меняешь сылки

ну, в линкед лист запихать элементы

а новая колекция это не копирование?

ты ничего не копируешь просто меняешь сылки

так изначально-то нету линкед-листа, так что в него надо скопировать

и изменить

все

а новая колекция это не копирование?

копирование, да, но если по ходу копирования еще и свои дела сделать, то всё равно один обход

так изначально-то нету линкед-листа, так что в него надо скопировать

val oldList = listOf(0, 1, 2, 3, 4, 5) val list = mutableListOf<Int>() oldList.forEachIndexed { index, item -> if (index != indexToRemove && index != indexToRemove - 1) { list.add(item) } }

:)

копирование, да, но если по ходу копирования еще и свои дела сделать, то всё равно один обход

это будет не краиво

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

ну вот да, о том и речь

val idx = list.indexOf(item) return list.subList(0, idx) + list.subList(idx + 2, list.size)

Имхо: самая приятная реализация из представленных

Имхо: самая приятная реализация из представленных

я её заменил на индексОф+фильтрИндексед в итоге

я её заменил на индексОф+фильтрИндексед в итоге

Почему?

потому что они менее подвержена ошибкам неверных индексов

fun removeCurrentNext(l: List<Int>, v: Int): List<Int> { val s = l.size - 1 return l.filterIndexed({i, x -> !(l[i] ==v || (i<s && i>0 && l[i-1] == v))}) }

Выглядит как скала)

простите, я только учусь

@Harmonizr презентация прекольная, думаю и сам доклад был неплохой

не успел)

)

А как названия функция которая делает зип с соседом?

zipWithNext?

А в котлине ассемблерные вставки делать можно?

я надеюсь ты про котлин нейтив

Я просто уснуть не могу, решил подумать над чем то глупым. Ищу единомышленников)

не ну просто если ты про котлин который под jvm то конечно нельзя

а на счёт котлин нейтив не знаю, вряд ли, во всяком случае ничего такого не гуглится

А в котлине ассемблерные вставки делать можно?

Нет, такого в котлине нет.

1. тернарный оператор - не ок 2. let2 - возможен 3. koin - ок либа 4. корутины - ок фича 5. ктор - ок либа 6. x?.let(f) ?: run(g) лучше заменить на if (x != null) f else g, особенно если f и g длинее пары слов 7. FP клевая штука, поэтому Котлин норм могет в FP(см val, лямбдочки, if/when expressions и т.д.), Typed FP - нет единогласного мнения, поэтому Котлин пока не оч могет в Typed FP, для желающих - arrow

Чем не ок только никто объяснить не может. :)

Чем не ок только никто объяснить не может. :)

Конкретно моё мнение: 1. Впринципе if-else может делать тоже самое. 2. Тернарный оператор очень располагает к нечитаемому использованию: a ? b : c это обычно смотрится хорошо, наверное даже лучше, чем if (a) b else c a ? (b ? c : d) : e или какая-либо другая вложенность смотрится мягко говоря сложно. С помощью if-выражений можно расписать намного читабельнее. Итого - есть один простой кейс, в котором иногда тернарный оператор смотрится чуть-чуть лучше чем if-else (отмечу, что if-else смотрится неплохо при if-else выражениях, а не присваиваниях как в джаве). И есть куча кейсов, когда лучше не использовать тернарный оператор. И ради одного действительно небольшого улучшения нужно ли вводить целый оператор?

Конкретно моё мнение: 1. Впринципе if-else может делать тоже самое. 2. Тернарный оператор очень располагает к нечитаемому использованию: a ? b : c это обычно смотрится хорошо, наверное даже лучше, чем if (a) b else c a ? (b ? c : d) : e или какая-либо другая вложенность смотрится мягко говоря сложно. С помощью if-выражений можно расписать намного читабельнее. Итого - есть один простой кейс, в котором иногда тернарный оператор смотрится чуть-чуть лучше чем if-else (отмечу, что if-else смотрится неплохо при if-else выражениях, а не присваиваниях как в джаве). И есть куча кейсов, когда лучше не использовать тернарный оператор. И ради одного действительно небольшого улучшения нужно ли вводить целый оператор?

Время на добавления всякого однообразного добра вроде let, run и пр. есть, а добавить простой по своей сути оператор нет. Это смешно:)

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

Время на добавления всякого однообразного добра вроде let, run и пр. есть, а добавить простой по своей сути оператор нет. Это смешно:)

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

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

Устраивать дебаты по этому поводу смысла не вижу. Мое мнение - место ему в языке есть.

Метадебат - разве такие чаты не нужны только для ведения таких дебатов и редких новостей/вопросов по языку? :)

Устраивать дебаты по этому поводу смысла не вижу. Мое мнение - место ему в языке есть.

Просто у вопросика уже есть один синтаксический смысл, а хорошей альтернативы не придумали; учитывая наличие ифа -- норм

Чем не ок только никто объяснить не может. :)

Java: if/else != ? :, потому что if/else не выражение. Kotlin: if/else == ? :, потому что if/else - выражение. Тем, кто жаждет тернарного оператора советую подумать, вдруг вам еще хочется альтернативный синтаксис для определения классов типа ©ClassName, или лямбды писать типа λx,y -> ... Можно еще для случаев когда нам нужно матчить просто инты ввести switch/case.

Таких сразу банить нужно

Всем привет, есть такая идея - передавать метод в который должен передаваться результат (в java я бы просто написал интерфейс ) public interface OnSuccessListener<T> { void onSuccess(T item); } но в Котлине я так понимаю это не прокатит, я попробовал следующие

но это мне не помогло, как вообще правильно в таких ситуациях поступать на котлине?

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

Всем привет, есть такая идея - передавать метод в который должен передаваться результат (в java я бы просто написал интерфейс ) public interface OnSuccessListener<T> { void onSuccess(T item); } но в Котлине я так понимаю это не прокатит, я попробовал следующие

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

спасибо, вроде понял, сейчас опробую

Да, все отлично, оказалось то что я написал работает, просто передавал неправильно

и еще такой момент, получается не важно как записывать так val viewFun: T.() -> Unit или val viewFun: (T) -> Unit ??

и еще такой момент, получается не важно как записывать так val viewFun: T.() -> Unit или val viewFun: (T) -> Unit ??

В одном параметр будет как this, в другом как it, вроде бы

в самой передаче да, а в приеме не важно?

и еще такой момент, получается не важно как записывать так val viewFun: T.() -> Unit или val viewFun: (T) -> Unit ??

В одном случае это функция, выполняющаяся рад T, а в другом функция, которая принимает T в качестве аргумента.

т.е. в моем случае все таки надо (T) , просто удивился, что отрабатывают одинаково