@Fsharp_chat

Страница 536 из 536
 
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
Стараюсь их избегать хотя-бы из-за дурацкого синтаксиса)

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