@Fsharp_chat

Страница 536 из 772
Vasily
04.04.2018
12:25:27
Я так понимаю, там дешевле отсортировать как надо при построении вьюшки

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

Klei
04.04.2018
12:25:35
Ты бегаешь по нему чаще чем его "считывает" вью?

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

Google
?‍?
04.04.2018
12:25:50
Ты бегаешь по нему чаще чем его "считывает" вью?
Да. Добавление в список изи, а вот удаление трудновато, как я понял из того, что видел на SOF - делают через матчи совпадения элементов и копирование в новый того, что не совпало с удаляемым (SOF он такой)

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

?‍?
04.04.2018
12:31:15
Если добавление нового чаще происходит около предыдущего, то я бы выбрал зиппер.
Добавление и удаление одинаково часто, а ссылку можно на пример?

Klei
04.04.2018
12:35:24
?‍?
04.04.2018
12:36:44
Я не про частоту, а про место добавления.
Место добавления не важно, место удаления - главное, чтобы удаляло

Klei
04.04.2018
12:37:03
Щас не вспомню, где можно найти. Но структура примитивна и редко используется в чистом виде, обычно сразу адаптируют. Но суть идеи: 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

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

Klei
04.04.2018
12:45:55
Roman
04.04.2018
13:47:05
https://twitter.com/holytshirt/status/981464641334398976?s=09

https://twitter.com/holytshirt/status/981464641334398976?s=09
@Kleidemos не совсем то, но резонирует

Google
Evgeniy
04.04.2018
14:05:45
> obj list

?‍?
04.04.2018
14:06:08
Evgeniy
04.04.2018
14:06:56
@yerumaku Это сознательная потеря типов? :(

?‍?
04.04.2018
14:07:29
@yerumaku Это сознательная потеря типов? :(
ну там вместо obj строгая типизация или <'t> - это же пример

Evgeniy
04.04.2018
14:12:35
https://twitter.com/kot_2010/status/981491210656403456

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

Evgeniy
04.04.2018
14:13:43
https://twitter.com/kot_2010/status/981491210656403456
гифка с Ченгом Придется открыть.

?‍?
04.04.2018
14:44:29
Зачем дублировать параметры из конструктора? Они же и так доступны. К тому же не вижу добавления и т.п.
Все let's сверну когда исчезнет надобность, там ещё в одной плоскости нужно будет двигать.

Vasily
04.04.2018
15:17:23
Я бы из мемберов вынес в модуль с таким же именем

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

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

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

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

Evgeniy
04.04.2018
17:06:47
Привет.

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

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

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

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

Klei
04.04.2018
19:23:51
в чем плюс модуля перед статик мемберами в типе?
Для внешнего использования разве что в возможности открытия модуля, что довольно таки редко.

Google
Klei
04.04.2018
19:24:48
А при написании тупо композировать проще.

Pavel
04.04.2018
19:25:34
что значит проще?

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

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

Evgeniy
04.04.2018
19:29:48
Klei
04.04.2018
19:36:29
А, еще есть проблемы с дженериками, иногда F# требует указывать тип обобщения для статических методов. Бесит невероятно.

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

Pavel
04.04.2018
19:40:25
А, еще есть проблемы с дженериками, иногда 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)

где требует?

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

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

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

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

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

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

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

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

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

Admin


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

Evgeniy
04.04.2018
21:37:51
https://twitter.com/thinkb4coding/status/981621813837991937

Roman
04.04.2018
21:38:36
https://twitter.com/thinkb4coding/status/981621813837991937
это что? мы под неткор сможем чтоль?

Evgeniy
04.04.2018
21:51:33
Roman
04.04.2018
21:54:12
Крутотень

Artemy
04.04.2018
22:31:25
https://github.com/Microsoft/visualfsharp/pull/4049

Roman
04.04.2018
22:36:58
SAFE.Template один из самых удобных

Pavel
05.04.2018
02:43:38
Стараюсь их избегать хотя-бы из-за дурацкого синтаксиса)
грызть кактус только потому что халва не такая красивая удовольствие сомнительное

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

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

Klei
05.04.2018
04:53:53
где требует?
Не могу найти. Когда столкнусь еще раз, напишу.

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

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

Alex
05.04.2018
06:19:44
?‍?
05.04.2018
06:23:19
Хотелось бы увидеть результат. Ибо щас не догоняю.
Есть условный список/зиппер. Пустой. В/из него drag'n'drop объекты. Для юзера они упорядочено выгрядят. Также сами объекты могут заменяться другими.

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

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

?‍?
05.04.2018
06:26:16
Удаление, как я понимаю, довольно редкая операция, и в целом ее можно с помощью List.filter сделать
Удаление, более редкое явление, а вот замена самое частое. Причем обычно по той же самой позиции.

Vasily
05.04.2018
06:26:53
И жизнь станет проще

Типа int*data

Klei
05.04.2018
06:27:15
Удаление, как я понимаю, довольно редкая операция, и в целом ее можно с помощью List.filter сделать
filter опасен, лучше рекусривно доходить до первого удовлетворяющего предикату, после чего фолдить накопенное через cons.

Страница 536 из 772