YS
Это скорее особенности стандратных либ
- Implementation details leak into BL through type classesэто значит что Implementation details leak into BL through LangL ?
Size: a a a
2020 May 25
АГ
>
это значит что Implementation details leak into BL through LangL ?
это значит что Implementation details leak into BL through LangL ?
Нет, через LangL при правильном дизайне языков детали не текут. На то она и абстракция, на то он и интерфейс.
Правда, для beam библиотеки в Hydra пришлось допустить протекания, и это сложный случай. Решаемый, но нужно больше времени.
Правда, для beam библиотеки в Hydra пришлось допустить протекания, и это сложный случай. Решаемый, но нужно больше времени.
YS
а что за бизнес логика такая у вас там? У меня вся логика - проверить что у пользователя есть права и он не дурак.
у меня грузчики записываются на заказы и приложения (и все вытекающие)
AV
Нет, через LangL при правильном дизайне языков детали не текут. На то она и абстракция, на то он и интерфейс.
подставь класс типов и получишь тоже самое
подставь класс типов и получишь тоже самое
NV
Есть интерфейсы, у них есть имплементация. Имплементации бывают нужны какие-то специальные данные. Например, хендлер логгерной библиотеки можно туда положить. Это детали имплементации, так как они проистекают из нативных подсистем. Эти детали должны быть скрыты, и потому их хорошо и правильно помещать в рантайм, которым будут пользоваться только интерпретаторы. Это примерно то же самое, как и инкапсуляция в ООП. Ты не видишь, что за интерфейсом, но каждая конкретная имплементация может хранить свои данные, нужные только ей. Клиент, пользующийся интерфейсом про эти данные не знает и знать не может
То есть вам нужно прокидывать контекст, который требуется имплементациям тайпклассов? Мне кажется, в TF это тоже очень хорошо решено через ридер-монадку
АГ
и типа если хочется смешать два языка - это противоречит SRP или вроде того
Это приводит к неясным последствиям. Само по себе смешение является механизмом, не относящимся к интерфейсу. Просто какая-то дополнительная тайп-левелная магия, видная из бизнес логики.
LO
у меня грузчики записываются на заказы и приложения (и все вытекающие)
ну т.е. проверить права и что не дурак, записать что-то в базу и чё-нить в очередь
YS
ну т.е. проверить права и что не дурак, записать что-то в базу и чё-нить в очередь
ну, там глянуть пересечение по времени заказов, глянуть может ли он туда записаться и прочеи и прочее
YS
хватает вроде .-.
YS
нужен ли он вообще там
LO
ну я к тому что чо там течёт то вообще?
АГ
Т.е. желание решить экспрешон проблем - это агрессивная тяга академиков писать код непрактично
Желание решить экспрешон проблем - это желание поиграться. Как правило, о реальных требованиях к проекту товарищи не вспоминают. А может оказаться так, что решать эту проблему вообще не нужно. Или же расширяемость достигается каким-то другим, более подходящим и простым способом, и там, где это нужно
YS
ну, у меня не течёт, у меня не используются стандартные тайпклассы
YS
IO не просунешь туда
АГ
Но ведь тф любители с этим не спорят
Зато я спорю
LO
ну сделаешь интерпретатор\мтл без IO и вся имплементашка будет размазана по Х файлов
Oℕ
Желание решить экспрешон проблем - это желание поиграться. Как правило, о реальных требованиях к проекту товарищи не вспоминают. А может оказаться так, что решать эту проблему вообще не нужно. Или же расширяемость достигается каким-то другим, более подходящим и простым способом, и там, где это нужно
Ну в моём опыте и опыте моих коллег, желание решить экспрешшон проблем - насущная необходимость
NV
Зато я спорю
Мне кажется мы нашли чучело
АГ
Не больше, чем наличие в языке возможности дернуть IO, которые у тебя в примерах было
Мой метод - черная дыра. Я явно сообщаю, что его использование нежелательно.
Но в отличие от, мой метод поддается контролю. Его даже замокать можно
Но в отличие от, мой метод поддается контролю. Его даже замокать можно
YS
ну сделаешь интерпретатор\мтл без IO и вся имплементашка будет размазана по Х файлов
ну в одном, но не суть