LO
Я думал в IO всё писать х)
протекает
Size: a a a
2020 May 27
YS
протекает
заткнуть!
к
Например?
я не знаю, но сейчас это выглядит практически как
type Increment = Int -> Int
increment :: Increment
increment x = x + 1
type Increment = Int -> Int
increment :: Increment
increment x = x + 1
YS
я не знаю, но сейчас это выглядит практически как
type Increment = Int -> Int
increment :: Increment
increment x = x + 1
type Increment = Int -> Int
increment :: Increment
increment x = x + 1
Тайпклассы же полиморфны по типам, и там не 1 к 1 .-.
YS
которые CanFind/Update/Create
к
да, там не 1к1, но из-за того что тип назван так же как функция, выглядит как 1к1
к
type ChangeWorkerStatusCapabilities
changeWorkerStatus
changeWorkerStatus
YS
Доводы твои я понял, но там тогда либо править в двух местах, либо править в n местах, если вместо алиаса писать как есть все 5 констрейнтов .-.
YS
Ну либо другой нейминг/другие тайпклассы
LO
слишком гранулярные констрейнты
к
да, другой нейминг поможет, он как минимум зафорсит не добавлять лишние констрейнты, которые не будут соответствовать неймингу
к
если например changeWorkerStatus нужен будет еще Show status условно, это это должно быть в changeWorkerStatus, а не в ChangeWorkerStatusCaps, хоть сейчас выглядит так будто именно в алиасе
YS
Немного не понял про "лишние констрейнты"
YS
слишком гранулярные констрейнты
есть такое( я пока хз, насколько это неправильно
YS
если например changeWorkerStatus нужен будет еще Show status условно, это это должно быть в changeWorkerStatus, а не в ChangeWorkerStatusCaps, хоть сейчас выглядит так будто именно в алиасе
снова не понял х(
YS
Ты говоришь, что неправильно добавлять констрейнты в алиас?
YS
Если ещё нужны будут
YS
(если что - я как бы докапываюсь или яро отстаиваю свою точку зрения, я действительно не понял)
к
1. да, я считаю что выносить констрейнты в алиас не нужно
2. но если выносить, то называть алиас не по имени функции, потому что иначе из-за нейминга между алиасом и функцией соответствие один к одному, и тогда не ясно зачем этот алиас, если можно прям в функции и написать констрейнты
3. если добавиться некая функция f, которая будет иметь те же констрейнты, то скорее всего их лучше скопировать, потому что совпание алиасов может быть случайно
4. сейчас алиас выглядит не как констейнты, нужные для обновления статуса, а как ВСЕ констрейнты, нужные для функции апдейта, из-за нейминга
5. если эта функция f будет использовать этот алиас, то если вдруг changeWorkerStatus вдруг затребует лишний констрейнт (например Show), то из-за нейминга будет мысль, что добавлять этот констрейнт нужно в алиас.
6. но для f этот Show будет не нужен
7. значит очевидно Show констрейнт должен быть в самой функции changeWorker, а не в алиасе
8. значит и алиас нужно назвать иначе, чтобы не было ложного соответствия
2. но если выносить, то называть алиас не по имени функции, потому что иначе из-за нейминга между алиасом и функцией соответствие один к одному, и тогда не ясно зачем этот алиас, если можно прям в функции и написать констрейнты
3. если добавиться некая функция f, которая будет иметь те же констрейнты, то скорее всего их лучше скопировать, потому что совпание алиасов может быть случайно
4. сейчас алиас выглядит не как констейнты, нужные для обновления статуса, а как ВСЕ констрейнты, нужные для функции апдейта, из-за нейминга
5. если эта функция f будет использовать этот алиас, то если вдруг changeWorkerStatus вдруг затребует лишний констрейнт (например Show), то из-за нейминга будет мысль, что добавлять этот констрейнт нужно в алиас.
6. но для f этот Show будет не нужен
7. значит очевидно Show констрейнт должен быть в самой функции changeWorker, а не в алиасе
8. значит и алиас нужно назвать иначе, чтобы не было ложного соответствия
AV
> 2. но если выносить, то называть алиас не по имени функции, потому что иначе из-за нейминга между алиасом и функцией соответствие один к одному, и тогда не ясно зачем этот алиас, если можно прям в функции и написать констрейнты
специальный полиморфизм же, как ты напишешь функцию?
специальный полиморфизм же, как ты напишешь функцию?