Ну идея такая

Ща у тебя есть CardName

и Card

Это можно объедлинить в один DU

И в зависимости от него брать/не брать из базы

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

Идея интересная. А можешь семпл кода дать?

type CardProxy= |NotLoaded of CardNumber |Loaded of Card

Дальше пишется обобщенная функция вытаскивания из базы, если надо

И условный deactivateCard - это (CardProxy->IoResult<CardProxy option>) list

type CardProxy= |NotLoaded of CardNumber |Loaded of Card

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

Так, стопэ

Тэкс

CardNumber- это номер банковской карты

Как я понимаю

В теории у нас тут может быть набор функций вида CardNumber->'t->CardNumber

Точнее

't->CardNumber->CardNumber

Тогда через паршиал апплай можно делать всякое

В теории у нас тут может быть набор функций вида CardNumber->'t->CardNumber

почему? Скорее CardNumber * SomeCommand -> IoResult<Card> Либо я не так тебя понял

Да

Ты прав

Если посмотреть на cardActions.fs

То если там везде убрать card в конец функции, можно получить много вкусного

там она не в конце только в пеймент и топ-ап. Я так сделал, чтобы можно было через паршал апплай сделать серию платежей и пополнений, хотя пока это еще нигде не используется. А ради чего туда карту в конец ставить?

Ну в теории у тебя тогда можно большие цепочки операций делать

И, возможно, код попроще будет

но ты же вряд ли будешь делать один и тот же платеж для разных карт?

как и пополнение

Мне лично не очень нравятся подобные сигнатуры: let setDailyLimit (currentDate: DateTimeOffset) (getCardAsync: CardNumber -> IoResult<Card option>) (replaceCardAsync: Card -> IoResult<unit>)

но ты же вряд ли будешь делать один и тот же платеж для разных карт?

Тут для одной карты же

Мне лично не очень нравятся подобные сигнатуры: let setDailyLimit (currentDate: DateTimeOffset) (getCardAsync: CardNumber -> IoResult<Card option>) (replaceCardAsync: Card -> IoResult<unit>)

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

Хотя я в энтерпрайзе ничо не понимаю :)

Ну я делаю мейлбокс обычно

В него зависимости

И уже его дергаю

Если надо, оверрайдю

типа у тебя DI в нем?

Ну условно

Чтобы можно было при желании заоверрайдить, например, получение из базы

но если у тебя там нет нужной зависимости, то свалится в рантайме, так?

но если у тебя там нет нужной зависимости, то свалится в рантайме, так?

Ну я ж по дефолту прописываю там все

Чтобы можно было при желании заоверрайдить, например, получение из базы

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

Одной из основных задач у меня было, чтобы как можно больше ошибок отлавливались в компайл тайме

Только желательно, чтобы параметры были после функций, конечно

Тогда это имеет смысл

А мейлбокс с DI это шаг в другом направлиении

Только желательно, чтобы параметры были после функций, конечно

не понял, ты про что?

ааа, текущую дату сдвинуть после зависимостей

let processPayment (currentDate: DateTimeOffset) (getCardAsync: CardNumber -> IoResult<Card option>) (getTodayOperations: CardNumber * DateTimeOffset * DateTimeOffset -> IoResult<BalanceOperation list>) (saveCardAsync: Card -> IoResult<unit>) (saveBalanceOperation: BalanceOperation -> IoResult<unit>)

да, имеет смысл

В теории currentDate должна быть в конце

гуд поинт, спасибо, поправлю

Ну и есть ощущение, что все это можно зверски упростить

Но надо подумать как

я пока не придумал)

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

не знаю, стоит ли считать популярность на pcj эффективностью

я пока не придумал)

Пока выглядит как оверинжиниринг

В теории currentDate должна быть в конце

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

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

Ну апишечку можно, да

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

А за di контейнер поясни

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

я пока против DI контейнеров) Все, что можно сделать в компайл тайме надо сделать в компайл тайме. Или иметь оочень веские причины сдвинуть все в рантайм

Поставил sbt для скалы, пытаюсь скомпилить какой-то простенький хеловорлд. Яебал время компиляции. @DogeShibu, как вы там живёте, чаи гоняете пока билдится?

Поставил sbt для скалы, пытаюсь скомпилить какой-то простенький хеловорлд. Яебал время компиляции. @DogeShibu, как вы там живёте, чаи гоняете пока билдится?

sbt можно в инкрементал моде ранать

Поставил sbt для скалы, пытаюсь скомпилить какой-то простенький хеловорлд. Яебал время компиляции. @DogeShibu, как вы там живёте, чаи гоняете пока билдится?

скала машина прогревает джава машину?

Это ты ещё не пробовал сложный код писать

Это ты ещё не пробовал сложный код писать

я походу скоро попробую.

я походу скоро попробую.

ЭТО ВОЛМАРТ!

прям с разбега на скалу

СО

или ОБ

был Айрат и вот его не стало?

А за di контейнер поясни

чего за него пояснять, ты видишь, насколько тупая сигнатура у функции только потому, что кто-то решил делать все правильно?

я походу скоро попробую.

Чо так? На фшарпе нет норм задач?

Чо так? На фшарпе нет норм задач?

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

чего за него пояснять, ты видишь, насколько тупая сигнатура у функции только потому, что кто-то решил делать все правильно?

Контекст надо передавать

От такого не отказываются наверное

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

Ну хз

От такого не отказываются наверное

НДА?

Контекст надо передавать

если самопальный - то да. а в нормальном DI за тебя все придумали уже