Ну в общем, это работает. теперь у нас в одном месте описание, а по коду летает не тыща разных функций, а несколько рекордов

про один сверху это конечно преувеличение

эти функции надо разбить на домены и происхождение

ваще, в мире классического ООП есть как бы read монада. она хорошо в композиции со state работает.

эти функции надо разбить на домены и происхождение

Из крестьян

ой

тьф

классического ФП

классического ФП

Сообщения можно редактировать!

ну и конкретно у меня получилось 4 рекорда основных в которых может по 10 параметров и ещё десяток функций которые ни туда, ни сюда, оставил их бултыхаться

у нас часть кода уже написана на рекордах из функций, щас чото начитался МС гайдлайнов и призадумался над интерфейсами

Да изи, берём значит кучу функций и запихиваем в один рекорд.

Вместо одного конструктора с N параметров получаем log N конструкторов :)

ну и конкретно у меня получилось 4 рекорда основных в которых может по 10 параметров и ещё десяток функций которые ни туда, ни сюда, оставил их бултыхаться

что ж там за названия?

что ж там за названия?

ты про названия рекордов или функций?

ты про названия рекордов или функций?

функицй в рекордах

ну допустим есть рекорд кешей, а есть рекорд асинхронных настроек

у нас часть кода уже написана на рекордах из функций, щас чото начитался МС гайдлайнов и призадумался над интерфейсами

А вот в данном случае - какая разница?

ну вот в рекорде кешей сидит всякая оперативная информация, в рекорде асинхронных настроек лежит глобальная статика которая вычитывается лейзи, ну и пр. Названия функций или полей рекорда особо ничего не скажут. MarginBoundCache например

вот да, что думаете насчет рекорды функций vs интерфейсы

понятно что в первом случае вывод типов

а во втором лучший interop c .net

вот да, что думаете насчет рекорды функций vs интерфейсы

и то, и другое. У меня есть рекорды с интерфейсами!

зачем отказываться?)

а как выбрать что когда?)

это уже очень для F#-специфично, менее интересный вопрос на самом деле

конфа же про f#?

ну я по умолчанию леплю рекорды, т.к. к ним можно методы привязывать, расширять (например дообъявить static member Empty для тестов)

большинство решений, которые будут удачны для f#, не будут удачны для хаскеля и прочих чисто фп языков

ну и тайп инфиренс к ним есть

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

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

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

можно, но это будет другой тип, с рекордом-то тот же

не то чтобы это была проблема, просто надо будет писать что-то вроде #Interface

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

в итоге иде не подсказывает сигнатуру

короче, это не взаимозаменяемые штуки, а взаимодополняющие

с тайп алиасами беда у IDE

Ну, вот ща Кжиштоф починит всё!

его наработки в ionide как-то отразятся на райдере?)

или это не про того парня

Про того :)

А причём тут райдер? :)

райдер - ide, vscode с ионидом уже не совсем) в моем понимании

А в моём - наоборот :)

Пробую ща райдер - и ваще никак

На самом деле райдеру сильно не хватает всяких тайпхинтов, рефакторингов, кодогенерации и прочего

Хорошо хоть ренейм подвезли

На самом деле райдеру сильно не хватает всяких тайпхинтов, рефакторингов, кодогенерации и прочего

а ты плюсуешь ишуи на ихнем ютраке?)

Конечно

И всех вокруг прошу)

а ты плюсуешь ишуи на ихнем ютраке?)

Ихуем

Ихуем

я специально!

Понимаю. Сам такой.

Не поминай имя господа в ишуе

а у меня мыло на иху

так чем там у стэк оверфлоу закончилось с ef.core? переехали?

Как заставить себя полюбить R?

в смысле immutable? там всё immutable

Такс, а кто у нас со всякими мемори/спанами плотно работал?

Интересует вопрос последовательной записи

а что с ним не так?

а что с ним не так?

С ними все так, интересует вопрос практического применения

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

Но потом может доехать еще кусок того же блоба

Но потом может доехать еще кусок того же блоба

Может тогда проще https://docs.microsoft.com/en-us/dotnet/api/system.buffers.arraypool-1.shared?view=netcore-2.2 ?

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

Ну мне же надо еще собирать сообщения из кусочков пришедших

Типа смотрю текущий стейт - ага, есть длина, так, дописываем, разбиваем, идем дальше

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

Ну я как бы преаллоцирую

я имел в виду финальный стейт

Ну смотри

У меня по tcp едет бинарный блоб

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

Вида длина:данные

Причем данные могут доехать и в следующем фрейме

понятно, в этих фреймах могуть быть разрезанные данные

Вот мне и надо эти данные собирать и кидать парсеру

Задача такая

а длина фреймов вменяемая для стека?

Ну там всякое может быть, конечно