У меня прокся орботовская. Сейчас вход из франции

Теперь вопрос к любителям выносить всё из классов в модули - как?

А зачем?

А зачем?

Евангелисты наверняка проделывали это. "Зачем" только они знают ответ.

Просто статики выносишь в модуль что ниже

Просто статики выносишь в модуль что ниже

и вынесеный оператор (*) убивает умножение

и вынесеный оператор (*) убивает умножение

Оператор выносить не надо

и вынесеный оператор (*) убивает умножение

Почему? Он же применяться должен только к типу Rec и sbyte, но тут еще вопрос, если компилятор избавляется в итоге от Measure, то какой метод будет вызываться и не будет ли конфликтов по итогу или же всё ок, тк собирается изначально правильно по меткам Measure?

namespace rec

Модуль надо поднять. )

namespace rec

м? в пространствах let's не будет

Так. Тип определяет в модуле

м? в пространствах let's не будет

https://github.com/fsharp/fslang-design/blob/master/FSharp-4.1/FS-1009-mutually-referential-types-and-modules-single-scope.md

Аа, по картинке сложно

Почему? Он же применяться должен только к типу Rec и sbyte, но тут еще вопрос, если компилятор избавляется в итоге от Measure, то какой метод будет вызываться и не будет ли конфликтов по итогу или же всё ок, тк собирается изначально правильно по меткам Measure?

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

> type X = { uid : int } let ( * ) (x : X) (a : int) = { x with uid = a } 5 * 8;; 5 * 8;; ^ D:\Temp\stdin(6,1): error FS0001: This expression was expected to have type 'X' but here has type 'int' >

Почему? Он же применяться должен только к типу Rec и sbyte, но тут еще вопрос, если компилятор избавляется в итоге от Measure, то какой метод будет вызываться и не будет ли конфликтов по итогу или же всё ок, тк собирается изначально правильно по меткам Measure?

Компилятор должен ругаться на твои операторы умножения. Ты собирал свой код?

Я обычно добавляю операторы после модуля через type extensions.

Да, в присутствии ошибок и сложных конструкций (например, перегрузок) редактор может сходить с ума и показывать непонятные сообщения.

Я обычно добавляю операторы после модуля через type extensions.

Не выходит. Тасую, но ни как.

Да, в присутствии ошибок и сложных конструкций (например, перегрузок) редактор может сходить с ума и показывать непонятные сообщения.

Хорошо, что пока всё понятно. Например теперь знаю, что inline для реализаций методов интерфейсов ломает ссылки на модули, стоящие выше

namespace rec

Часто приходится использовать в реальных проектах?

Часто приходится использовать в реальных проектах?

Я использую как раз для операторов, которые вызывают функции модуля.

namespace/module rec отлично справляются с обязанностями, которые на них возложили евангелисты (лол!) модулей.

Чет я не могу понять, какую задачу хочется решить

Чет я не могу понять, какую задачу хочется решить

Никакую. :)

А, понаркоманить

Все как мы любим!

В целом, я бы рекомендовал посмотреть на концепцию dependency property в wpf

Чет я не могу понять, какую задачу хочется решить

Чтобы записывалось как рекорд3, и чтобы тип был свободен от мемберов-функций, то есть логика лежала в модулях и расширениях, (как это типа принято в сообществе).

А зачем? Какая задача решается таким вот способом?

Пока у меня впечатление, что список свойств тут бы подошёл лучше

Пока у меня впечатление, что список свойств тут бы подошёл лучше

А это что за зверь?

А зачем? Какая задача решается таким вот способом?

По первой части: Простота изменения части записи, когда запись представлеят из себя маленькую структуру. По второй части: Так советуют делать практиканты, набивать руку так сказать уже сейчас, да и мне хочется научиться плавать в синтаксисе, чтобы знать что язык может, а чего нет.

https://hastebin.com/kiwovakujo.fs

Вот это имел в виду @Kleidemos.

@yerumaku Выкладывай, пожалуйста, большие листинги кода на пастебин, например.

А это что за зверь?

Ну список объектов типа "свойство"

Обычный list

в результате теперь чтобы создать/изменить новую проперть (вместо того чтобы компактно собрать эту логику в одном месте) нужно скакать по листингу в 3-х местах

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

Есть ещё концепция депенденси пропертей, но она довольно сильно завязана на инстанцированные объекты ,у которых к тому же должны быть более-менее уникальные айдишники

Короче, я про что

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

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

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

Ты бы лучше подсказал @yerumaku, что ``with P1 =`` и бездумное использование стандартных операторов — смерти подобно с точки зрения дальнейшей поддержки.

@yerumaku Выкладывай, пожалуйста, большие листинги кода на пастебин, например.

Ок https://hastebin.com/afekakayew.sf

ну его with.... не смертелен и чем то даже может помочь в почитании написанного лет через 5, но по сути баловство и быстро надоедает. а операторы да. стандартные операторы должны реализовывать только стандартное поведение (умножение должно остаться умножением).

Когда возникают проблемы подобного рода, скорее всего нужны другие структуры данных

Ты бы лучше подсказал @yerumaku, что ``with P1 =`` и бездумное использование стандартных операторов — смерти подобно с точки зрения дальнейшей поддержки.

Это всё искусственное, для отражения логики, не более

Когда возникают проблемы подобного рода, скорее всего нужны другие структуры данных

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

Список объектов типа свойство?

По факту рекорд - тот же список. И класс тоже

Список объектов типа свойство?

Я что-то плохо себе представляю.

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

Ты не обладаешь монополией на правильные взгляды по поддержке кода.

@gsomix ,а я согласен с @deexpp , что поддержка кода важна

Я что-то плохо себе представляю.

Ну обычный список

@gsomix ,а я согласен с @deexpp , что поддержка кода важна

Кажется, речь была про истинно верный способ организации кода. И про то, что мне "все равно".

¯\_(ツ)_/¯

Есть объект свойство, у него есть имя и значение

Кажется, речь была про истинно верный способ организации кода. И про то, что мне "все равно".

Ну @deexpp слегка категоричен, да. Это тоже вредит, хоть и повышает самооценку за счёт опускания самооценки других

Ну и я бы не был столь уверен, что существует правильный способ

От задачи много зависит, и от бэкграунда

Ну обычный список

Сколько это будет в памяти? Без примера или ссылки на что смотреть это тёмный лес.

Ну смотри

Можно сделать на спанах

Тогда небольшой оверхед

Можно сделать на стандартных структурах- там уже на мобиле миллиардами записей не поворочаешь

Можно сократить, если есть общие свойства

Так в впф сделано, например

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

Да проблем там много

Вопрос в том, как их решить

@yerumaku если у тебя много свойств шарится,погляди все же на концепцию депенденси пропертей, они здорово экономят память

Опять же, если быстродействие не очень важно,можно мемори маппед файлами побаловаться

@yerumaku если у тебя много свойств шарится,погляди все же на концепцию депенденси пропертей, они здорово экономят память

В смысле шарится? С подключаемыми свойствами давно уже не работал, наверно так с 8.1 или старта uwp, не вижу применимости в данном случае. Там нет миллиардов, менять надо по щелчку, без рефлексий или ещё какого шаманства с укладыванием в словарь.

Ну если там нет миллиардов, откуда такой оверинжиниринг памяти?

Ну если там нет миллиардов, откуда такой оверинжиниринг памяти?

I'm <3 IT Это не единственная структура в программе, помимо неё еще куча, в разных количествах, + есть среда UI, которая будет кушать ОЗУ, а мне и пользователю не хочется, чтобы ОС убивала приложение, потому что другому приложению без оптимизации памяти она сейчас нужнее.

По факту ты здесь экономишь копейки за счет некоторых сверхусилий

Где-то у меня была прикопана серия статей по этому поводу

https://ayende.com/blog/176034/making-code-faster-the-interview-question

Во, рекомендую

Хоть и с#, но посыл там правильный

По факту ты здесь экономишь копейки за счет некоторых сверхусилий

https://t.me/Fsharp_chat/54141

А, ну если цели научно-познавательные, то ок

сам люблю понаркоманить

Tests.Unit428 не смутил (:

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

Через 9 с небольшим дней. http://fsharpconf.com/

Лайвстрим.

Мда, объясните тупому, как вскод настроить для дебага