filter опасен, лучше рекусривно доходить до первого удовлетворяющего предикату, после чего фолдить накопенное через cons.

В смысле? Внутри DU, которые сортируются по типу сначала, и по содержанию между собой. Пока что лежат списком, но вот возникает трабл с синтаксимом удаления элементов. static member ``sort by type`` obj = match obj with | A (record) -> 0b000001 <<< 26 ||| record.uid >>> 5 | B (record) -> 0b000010 <<< 26 ||| record.uid >>> 5 | C (record) -> 0b000100 <<< 26 ||| record.uid >>> 5 | D (record) -> 0b001000 <<< 26 ||| record.uid >>> 5 | E (record) -> 0b010000 <<< 26 ||| record.uid >>> 5

На 20 элементов пойдёт, по идее

filter опасен, лучше рекусривно доходить до первого удовлетворяющего предикату, после чего фолдить накопенное через cons.

А если filter снесет 2 и более элемента? Или вообще ничего не уберет.

Хранить индексы? А кто будет следить за корректностью индексов после удаления/добавления?

Там получается может быть 2 элемента с одним предикатом, но с разными record data

Я даже предметную область не могу для себя до конца сформулировать

Пример с ходу - внесение цепочек мутаций в ДНК, где мутации группируются по свойствам

Т.е. набор мапов,как я понимаю

В виде obj простой рекорд внутри DU, где его часть превращается с помощью (>>>) и (<<<) в uid, где 5 bit не играют особой роли в сортировке, а вот DU ветви играют.

Есть свойство мутации как объекта доменной области

Погоди, давай вернёмся на более абстрактный уровень

Такс.С этим разобрались. Идём дальше. Какие объекты меняет пользователь?

DU из небольшого числа ветвей. uid получается как DU ветвь id + часть record data

Это детали имплементации. Мне пока более необходимо разобраться с предметной областью

Юзер меняет само влияение1 и силу_влияния1, влияние2 и силу_влияния2

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

Вот.Т.е. у нас есть кортеж влияние * сила,так?

Следующий вопрос. У мутации есть другие параметры, кроме вышеописанного кортежа?

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

Чтобы сортировать на нижнем уровне. Напимер из map будет тянуться статика через uid >>> 20

Не проще два идентификатора завести?

Один на статику, другой на динамику?

Т.е. речь идет о миллиардах записей, так?

Ну на мобилке пару гигов памяти ща можно найти, насколько я помню

Количество свойств на мутацию ограничено же?

Всю эту битмапщину в структуру завернуть нельзя? Чтобы по памяти был int, а по доступу - няшное типизированное

Всю эту битмапщину в структуру завернуть нельзя? Чтобы по памяти был int, а по доступу - няшное типизированное

Короче, в виде кода текущую доменную область можно увидеть?

DU в данном случае - это тип мутации?

И там свойства захардкожены?

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

Удаление, более редкое явление, а вот замена самое частое. Причем обычно по той же самой позиции.

https://twitter.com/dsyme/status/981810979465023488

Вагиф разжигает. :) https://twitter.com/ooobject/status/981811655804882945

Вагиф разжигает. :) https://twitter.com/ooobject/status/981811655804882945

надеюсь это сарказм

Да, там в комментах в твиту выясняли. :)

Сарказм, потому что там нугет ?

Блин, это отличный наброс. :)

Ты тоже не сразу распознал сарказм?

Думаю дальше будет. Это же один слайд

Ну, там вообще доклад про сообщество, а не про технологии.