ŹR
Так же как и протоколы
Size: a a a
2019 July 29
AN
Ну мы же щас не про глубинное мироустройство
ŹR
Но у тебя же нету типов
AN
Почему нету?
ŹR
Тв хочешь раздрочить костылей, чтобы воспользоваться фичей которая компилируется в паттерн матчинг вместо того чтобы просто руками написать паттерн матчинг?
AN
Есть типы A, B, C.
У них много общего: поля (x, y), валидации, поведение.
Есть отличия: extra поля, поведение.
Идеальное решение, вид снаружи:
Как сделать без макроса, чтобы не дублировать описание общих полей, общих валидации и другого общего. Да, у меня получилось наследование. Как сделать, чтобы не было наследования, но не было повторения описания общих частей?
У них много общего: поля (x, y), валидации, поведение.
Есть отличия: extra поля, поведение.
Идеальное решение, вид снаружи:
%A{x: 1, y: 2, super_field: 123123}%B{x: 1, y: 2, super_field: "stroka"}%С{x: 3, y: 4, super_pooper_field: ["a", "a"]}Как сделать без макроса, чтобы не дублировать описание общих полей, общих валидации и другого общего. Да, у меня получилось наследование. Как сделать, чтобы не было наследования, но не было повторения описания общих частей?
AN
Тв хочешь раздрочить костылей, чтобы воспользоваться фичей которая компилируется в паттерн матчинг вместо того чтобы просто руками написать паттерн матчинг?
Следует ли это читать как «Протоколы не нужны»?
AN
Или они только для расширения чужого кода (своего на чужой стороне)?
ŹR
Если ты из бд прочитаешь all, у тебя будет список с A,B,C?
ŹR
Ответ - нет. Тогда с чего ты решил, что у тебя есть типы?
AN
Когда я делаю all мне не нужно знать про extras и тип. Но type там тоже может быть
Мне нравится в протоколах, что с ними нет одной жирной точки, где что-то знает про соответствие типа и поведения. Добавился тип коннектора? Добавился один файлик с типом и имплементацией протокола
Мне нравится в протоколах, что с ними нет одной жирной точки, где что-то знает про соответствие типа и поведения. Добавился тип коннектора? Добавился один файлик с типом и имплементацией протокола
P
Ну макросы - это магия, чтобы понять как это работает, придется понять макрос. Однако если ты вместо макроса добавишь паттерн-матчинг на обработку этого коннектора, то это будет более явно.
ŹR
Надо использовать behavior в этом случае
ŹR
И хранить его название в бд
ŹR
А потом динамически диспатчить
P
Вот я тоже за такой подход
ŹR
Протоколы это ебала на самом деле
ŹR
Прям редко нужны
P
Диспетчер + паттерн-матчинг (1 строка для каждого нового коннектора) + коннекторы завязанные на протоколах. Выглядят и гибко и понятно. Чтобы не писать дефы как-раз можно в диспетчере написать минимальный макро-код, чтобы генерировать это на лету из списка типов)