Как писать полиморфические программы c помощью Arrow

[xGromMx]

полиморфические :D

[vdem]

Вы бы сначала дали определение «полиморфической» программы. Слышал про полиморфные вирусы, которые модифицируют собственный код для усложнения их обнаружения по сигнатурам. Знаю о полиморфизме в ООП. Но о «полиморфических» программах не слышал никогда ранее.

[dougrinch]

Спасибо за пост, было очень интересно прочитать.

Концепция прикольная, но в целом настроен довольно скептично. Если привнесение функциональных map/flatMap/filter/etc. в контейнеры действительно сильно облегчает работу с ними, то этот следующий уровень абстракции уже кажется перебором. Глобально я вижу две проблемы:

1. Это очень сильно увеличивает сложность, давая взамен непонятно что. И User, и Task — это объекты доменной модели, а значит весь DataSource имеет смысл только внутри проекта, я не буду выносить его в "глобальную общую либу". А внутри проекта иметь такую мощную параметризацию уже не так критично, все равно внутри проекта везде используется один и тот же контейнер, а для тех редких мест, где его надо передать в либу, всегда есть экстеншн методы типа Iterable<T>.asSequence(): Sequence<T>. Да, иметь теоретическую возможность в любой момент перейти с Rx на корутины/что-нибудь еще, приятно, но давайте будем честны, все равно не получится. Все равно завязка на конкретную либу гораздо больше, нежели один вызов DeferredK.async(). Это как с БД — sql как бы стандартизован, но, почему-то, смена базы никогда не бывает простой.
2. Это ведь все равно не работает! Потому что в реальности я не хочу Observable<List<Task>>, я хочу Observable<Task>. Концепция последовательности элементов там уже есть внутри. В конце концов, мои таски могут получаться батчами из какого-нибудь микросервиса, и я не хочу ждать все батчи лишь для того, чтобы начать обрабатывать первый таск. А если и на моей стороне обрабатывать лучше батчами, то я хочу написать Observable<Task>.batched(limit, timeout): Observable<List<Task>> (на rx не писал, поэтому с названием мог промазать, но подобное там обязано быть), а не полагаться на сабмитера этих тасков. Получается, что заменить Observable<Task> на Single<Task> просто нельзя. И если для семантики контейнера с отложенным содержимым авторы библиотеки Async<F> написали, то для семантики контейнера с неопределенным числом элементов — нет.

[artem_dobrovinskiy]

Спасибо за отличный комментарий.

Описанный подход — не серебрянная пуля, а больше пример того, как можно думать. Могу ошибаться, но мне кажется, Вы пытаетесь примерить подход на какие-то существующие решения, возможно на те, с которыми сейчас работаете. Если это так, то да, ничего не заработает. Потому что люди, которые писали Вам api и которые работали над проектом до вас скорее всего не оставили Вам места для маневров с высокими типами.

А по моему опыту трудности смены базы/фреймворка в проекте чаще всего связаны именно с отсутствием абстракции высокого уровня требуемых к замене частей. Тут-то что-то вроде Kind<T, R> очень может выручить.

[dougrinch]

Как можно думать — это да, именно за это и люблю подобные посты. Я не столько пытаюсь примерить подход на существующие решения, сколько вижу проблему в общем случае — мы пытаемся внести абстракцию туда, где нам важны детали реализации.

Банально, возвращаясь к моему примеру, как правильно сделать, если я хочу не «какой-то контейнер, содержащий один лист чего-то», а «какой-то контейнер, содержащий несколько элементов чего-то»?

[basnopisets]

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