Телеграмм чат группы oop

и я вот думаю, что лучше делать:

import { x, y, z } from "./bottom"
export function getXYZ({
  xProps,
  yProps,
  zProps,
}: XYZProps): XYZ {
  return {
    x: x(xProps),
    y: y(yProps),
    z: z(zProps),
  };
}

или

import { x, y, z } from "./bottom"
export function getXYZ(): XYZ {
  return {
    x: x,
    y: y,
    z: z,
  };
}

20:20пожаловаться #1

NF

в первом случае получится в корне как xyz(fgh()), во втором xyz.x(fgh.f(...)) x3

20:26пожаловаться #2

NF

и на этом моменте я немного теряюсь, ведь с одной стороны делать интерфейс из данных это "тру фп", с другой стороны если так делать, то функциональный подход с "зависимости всегда первым аргументом" не работает, меня прям тянет сделать интерфейс class-like, тогда "зависимости всегда первым аргументом" работает, но интерфейс получается из кода, а не из данных.

20:35пожаловаться #3

NF

короче либо я что-то делаю не так, либо есть какое то правило чтобы делать этот выбор, так вот что это за правило?

20:39пожаловаться #4

YG

короче либо я что-то делаю не так, либо есть какое то правило чтобы делать этот выбор, так вот что это за правило?

Мб кто другой поможет, ибо я не оч понял. Но похоже что проблема с пробросом зависимостей в нижние модули. Чаще всего решается монадами. Из простых примеров ReaderMonad

20:52пожаловаться #5

NF

Мб кто другой поможет, ибо я не оч понял. Но похоже что проблема с пробросом зависимостей в нижние модули. Чаще всего решается монадами. Из простых примеров ReaderMonad

монады это кастыль для ущербных))

20:53пожаловаться #6

YG

монады это кастыль для ущербных))

Хм, ну мб тогда тебе и не нужно это фп)

21:00пожаловаться #7

YG

Получается, просто код в "нижних" модулях формата (deps, args) => output,
дальше с подъемом выше они группируются через 1 импорт из index в отдельном модуле, т.е. import { x, y, z } from "./bottom" + (deps, args) => output
и так до рута, а в руте 100500 импортов внешних модулей и явная установка их в deps

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

21:09пожаловаться #8

YG

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

21:10пожаловаться #9

NF

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

я просто каррирую и вниз передается только нечто вроде:
deps: { getChanges: (id, field) => timetravel.getChanges(timetravel.initialState, id, field) }
ну или какой-то более разумный интерфейс

21:14пожаловаться #10

YG

я просто каррирую и вниз передается только нечто вроде:
deps: { getChanges: (id, field) => timetravel.getChanges(timetravel.initialState, id, field) }
ну или какой-то более разумный интерфейс

Ну шо то какая то залупка) а зачем ты так делаешь? Что это даёт из бенефитов?

21:19пожаловаться #11

NF

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

21:19пожаловаться #12

NF

Ну шо то какая то залупка) а зачем ты так делаешь? Что это даёт из бенефитов?

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

21:21пожаловаться #13

NF

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

21:26пожаловаться #14

NF

у каждого модуля интерфейсы с 2 сторон i/o, по этому можно не бояться что-то где-то сломать, изменяя i/o я всегда могу сделать это от в 1-3 местах максимум, чаще в 1

21:31пожаловаться #15

YG

The question of “How do I design my application in Haskell?” comes up a lot.There’s a bunch of perspectives and choices, so it makes sense that it’s difficul...

у каждого модуля интерфейсы с 2 сторон i/o, по этому можно не бояться что-то где-то сломать, изменяя i/o я всегда могу сделать это от в 1-3 местах максимум, чаще в 1

Круто. Ну это вроде не совсем про чистые функции. Где результат зависит только от аргументов.

Есть вот ещё такое известное чтиво https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html

www.parsonsmatt.org

Three Layer Haskell Cake

21:33пожаловаться #16

NF

The question of “How do I design my application in Haskell?” comes up a lot.There’s a bunch of perspectives and choices, so it makes sense that it’s difficul...

Круто. Ну это вроде не совсем про чистые функции. Где результат зависит только от аргументов.

Есть вот ещё такое известное чтиво https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html

www.parsonsmatt.org

Three Layer Haskell Cake

ну они все у меня чистые, грязный только корень точнее дерево корней

Алексей Гевондян... in Software Design/Architecture/Zen

21:37пожаловаться #17

АГ

ну они все у меня чистые, грязный только корень точнее дерево корней

🙃