Я так понимаю, там дешевле отсортировать как надо при построении вьюшки

Чем что-то ниже городить

Ты бегаешь по нему чаще чем его "считывает" вью?

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

Ты бегаешь по нему чаще чем его "считывает" вью?

Да. Добавление в список изи, а вот удаление трудновато, как я понял из того, что видел на SOF - делают через матчи совпадения элементов и копирование в новый того, что не совпало с удаляемым (SOF он такой)

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

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

Добавление и удаление одинаково часто, а ссылку можно на пример?

Добавление и удаление одинаково часто, а ссылку можно на пример?

Я не про частоту, а про место добавления.

Я не про частоту, а про место добавления.

Место добавления не важно, место удаления - главное, чтобы удаляло

Щас не вспомню, где можно найти. Но структура примитивна и редко используется в чистом виде, обычно сразу адаптируют. Но суть идеи: type 'a Zipper = Left : 'a list * Right 'a list module Zipper = let add item (Zipper (left, right)) = Zipper(left, item::right) let tryMoveRight (Zipper (left, right)) = match right with | h::t -> Zipper (h::left, t) |> Some | [] -> None

По необходимости добавляй.

Щас не вспомню, где можно найти. Но структура примитивна и редко используется в чистом виде, обычно сразу адаптируют. Но суть идеи: type 'a Zipper = Left : 'a list * Right 'a list module Zipper = let add item (Zipper (left, right)) = Zipper(left, item::right) let tryMoveRight (Zipper (left, right)) = match right with | h::t -> Zipper (h::left, t) |> Some | [] -> None

Не могу понять где тут удаление из левого/правого списка, при добавлении в правую/левую часть. ([], 1, [2; 3; 4]) ([1], 2, [3; 4]) ([2; 1], 3, [4])

Хотя... h(ead)::t(body), всё понял

Не могу понять где тут удаление из левого/правого списка, при добавлении в правую/левую часть. ([], 1, [2; 3; 4]) ([1], 2, [3; 4]) ([2; 1], 3, [4])

Сам решай, что есть current, расширяй add так, что бы current удовлетворял твоим условиям.

https://twitter.com/holytshirt/status/981464641334398976?s=09

https://twitter.com/holytshirt/status/981464641334398976?s=09

@Kleidemos не совсем то, но резонирует

> obj list

> obj list

?

@yerumaku Это сознательная потеря типов? :(

@yerumaku Это сознательная потеря типов? :(

ну там вместо obj строгая типизация или <'t> - это же пример

https://twitter.com/kot_2010/status/981491210656403456

Зачем дублировать параметры из конструктора? Они же и так доступны. К тому же не вижу добавления и т.п.

https://twitter.com/kot_2010/status/981491210656403456

гифка с Ченгом Придется открыть.

Зачем дублировать параметры из конструктора? Они же и так доступны. К тому же не вижу добавления и т.п.

Все let's сверну когда исчезнет надобность, там ещё в одной плоскости нужно будет двигать.

Я бы из мемберов вынес в модуль с таким же именем

Реально снимает много проблем

Связанных с привычкой к ооп

Я бы из мемберов вынес в модуль с таким же именем

Как методы расширений? Модуль даст + один класс в метаданные, а если так делать с каждым классом, может быть немного не наглядно, сейчас меньше всего хочется запутаться почему тут не рекорд или не DU (ещё + один класс в метаданные)

Связанных с привычкой к ооп

Если я правильно понял на счёт расширений, то пока так делаю для интерфейсных методов.

Привет.

Как методы расширений? Модуль даст + один класс в метаданные, а если так делать с каждым классом, может быть немного не наглядно, сейчас меньше всего хочется запутаться почему тут не рекорд или не DU (ещё + один класс в метаданные)

Имелось ввиду, что создается тип и одноименный модуль. Все операции над типом производится посредством функций (если не требуют инкапсуляции). Делается это для того, чтобы не возиться с лямбда адом (List.iter (fun p -> p.Method()) против List.iter MyType.method). К тому же можно создавать одноименные модули в конкретных областях, что позволяет изолировать ограниченно необходимые функции там где надо, а не мозолить ими глаза по всему проекту. Как правило для иммутабельных типов единственная причина иметь приватные методы, это доступ к скрытым от внешнего наблюдателя данным или дополнительная логика публичного конструктора, которую нет смысла выполнять, если есть гарантия корректности нового объекта. И это не твой случай (судя по тому что видели). // Случай приращение методов к типу на основе функций - лишь хороший тон. Что касается метаданных и "лишних" типов, то в F# принято плодить чудовищную орду мелких типов. Каждый из которых гарантировал бы корректность строго определенной части данных. Понятное дело, что сейчас никто не в праве заставлять тебя писать "правильно". Просто будь готов, что по мере приобритения опыта ты начнешь естественным образом склоняться к вышеописанным практикам, и будем лучше, если ты не будешь противодействовать этим тенденциям из-за инерции сознания.

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

Имелось ввиду, что создается тип и одноименный модуль. Все операции над типом производится посредством функций (если не требуют инкапсуляции). Делается это для того, чтобы не возиться с лямбда адом (List.iter (fun p -> p.Method()) против List.iter MyType.method). К тому же можно создавать одноименные модули в конкретных областях, что позволяет изолировать ограниченно необходимые функции там где надо, а не мозолить ими глаза по всему проекту. Как правило для иммутабельных типов единственная причина иметь приватные методы, это доступ к скрытым от внешнего наблюдателя данным или дополнительная логика публичного конструктора, которую нет смысла выполнять, если есть гарантия корректности нового объекта. И это не твой случай (судя по тому что видели). // Случай приращение методов к типу на основе функций - лишь хороший тон. Что касается метаданных и "лишних" типов, то в F# принято плодить чудовищную орду мелких типов. Каждый из которых гарантировал бы корректность строго определенной части данных. Понятное дело, что сейчас никто не в праве заставлять тебя писать "правильно". Просто будь готов, что по мере приобритения опыта ты начнешь естественным образом склоняться к вышеописанным практикам, и будем лучше, если ты не будешь противодействовать этим тенденциям из-за инерции сознания.

Напиши статью )

Хз. В принципе я своим точно так же мозги промываю, еще полгода и перейду на заученный/выработанные формулировки.

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

в чем плюс модуля перед статик мемберами в типе?

в чем плюс модуля перед статик мемберами в типе?

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

А при написании тупо композировать проще.

А при написании тупо композировать проще.

?

что значит проще?

Ты в курсе, что статические методы внутри класса вызываются через его полное имя? Будет у тебя какой нибудь 'static member map ...' и ты будешь его таскать по всему классу в виде 'MyType.map'.

Ясное дело, можно статик лет, с последующим прокидыванием, но зачем?

в чем плюс модуля перед статик мемберами в типе?

В модуле можно типы объявлять.

Ты в курсе, что статические методы внутри класса вызываются через его полное имя? Будет у тебя какой нибудь 'static member map ...' и ты будешь его таскать по всему классу в виде 'MyType.map'.

в курсе.

Ясное дело, можно статик лет, с последующим прокидыванием, но зачем?

из C# дергать удобнее

В модуле можно типы объявлять.

если модуль заводится чисто для функций типа то встретить в нем новые типы будет неожиданно

если модуль заводится чисто для функций типа то встретить в нем новые типы будет неожиданно

Он не чисто для функций, он для работы с типом.

А, еще есть проблемы с дженериками, иногда F# требует указывать тип обобщения для статических методов. Бесит невероятно.

Хотя это не про то.

А, еще есть проблемы с дженериками, иногда F# требует указывать тип обобщения для статических методов. Бесит невероятно.

type V<'t> = V of 't with static member value (V e) = e static member apply f (V e) = V (f e) [ V 1; V 2 ] |> List.map (V.apply ((+)1) >> V.value)

где требует?

@deexpp Ты бы лучше свою мысль напрямую донес, без сократовских замашек. :)

@deexpp Ты бы лучше свою мысль напрямую донес, без сократовских замашек. :)

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

но собственно мысль проста. статик мемберы удобнее модуля для типа

Стараюсь их избегать хотя-бы из-за дурацкого синтаксиса)

Стараюсь их избегать хотя-бы из-за дурацкого синтаксиса)

+

Ну я попробовал и статические мемберы,и модули, с модулями классы, торчащие наружу,получаются почище

Условно, я объявляю рекорд, и к нему в пару модуль, который содержит create,empty etc

С моей точки зрения, происходит более чистое разделение данных и операций над ними

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

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

Другой вопрос, что модулю нельзя навесить CompiledName по понятным причинам, поэтому из c# код будет выглядеть странновато

https://twitter.com/thinkb4coding/status/981621813837991937

https://twitter.com/thinkb4coding/status/981621813837991937

это что? мы под неткор сможем чтоль?

это что? мы под неткор сможем чтоль?

Да, работает.

Крутотень

https://github.com/Microsoft/visualfsharp/pull/4049

SAFE.Template один из самых удобных

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

type extension никто не отменял. навешивай новое поведение сколько угодно

Стараюсь их избегать хотя-бы из-за дурацкого синтаксиса)

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

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

Кактусом здесь выступают как раз статические методы, а никак не модуль. Из всего перечисленного мне изредка пригождаются разве что операторы. Вообще использование статических методов вначале использования F# является делом привычки, и если уж народ переезжает на модули, значит для этого есть причины.

Есть несколько объектов (до ≈20), которые нужно периодически сортировать после добавления новых/удаления старых. Что лучше использовать, спискок, массив, что-то ещё?

Мб SortedList какой-нибудь?

где требует?

Не могу найти. Когда столкнусь еще раз, напишу.

* А зачем столько сопоставлений? Там же достаточно одной проверки current, и двух реакций на нее. * Тебе точно нужен null? Если хочешь иметь отдельно стоящий current, то может хотя бы на option перейдешь? * Нет логики поддержания порядка сортировки.

* А зачем столько сопоставлений? Там же достаточно одной проверки current, и двух реакций на нее. * Тебе точно нужен null? Если хочешь иметь отдельно стоящий current, то может хотя бы на option перейдешь? * Нет логики поддержания порядка сортировки.

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

Тогда я перестаю понимать, зачем здесь zipper? Он удобен для упорядоченного хранения, редкого упорядоченного и частых неупорядоченных прохождений. Если порядок никак не влияет на внутренюю логику, то есть резон просто хранить list (и по желанию при построении вью пробрасывать упорядоченный список обратно,)

Тогда я перестаю понимать, зачем здесь zipper? Он удобен для упорядоченного хранения, редкого упорядоченного и частых неупорядоченных прохождений. Если порядок никак не влияет на внутренюю логику, то есть резон просто хранить list (и по желанию при построении вью пробрасывать упорядоченный список обратно,)

> Если порядок никак не влияет на внутренюю логику, то есть резон просто хранить list Выше писал, что не понимаю как удалять из списка. В Zip удобно производить поиск удаляемого.

https://twitter.com/thinkb4coding/status/981621813837991937

Наконец то ^_^

> Если порядок никак не влияет на внутренюю логику, то есть резон просто хранить list Выше писал, что не понимаю как удалять из списка. В Zip удобно производить поиск удаляемого.

Хотелось бы увидеть результат. Ибо щас не догоняю.

Хотелось бы увидеть результат. Ибо щас не догоняю.

Есть условный список/зиппер. Пустой. В/из него drag'n'drop объекты. Для юзера они упорядочено выгрядят. Также сами объекты могут заменяться другими.

Удаление, как я понимаю, довольно редкая операция, и в целом ее можно с помощью List.filter сделать

Тем более если элементов немного

Удаление, как я понимаю, довольно редкая операция, и в целом ее можно с помощью List.filter сделать

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

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

Введи в доменную модель понятие индекса

Тем более если элементов немного

≈5-20

И жизнь станет проще

Типа int*data

Удаление, как я понимаю, довольно редкая операция, и в целом ее можно с помощью List.filter сделать

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