AB
> Всё остальное можно оставить интерпретируемым языкам
вот ты сейчас меня убить пытался
вот ты сейчас меня убить пытался
> Всё остальное можно оставить интерпретируемым языкам
вот ты сейчас меня убить пытался
Size: a a a
2021 March 03
LL
Ну, у нас же есть компайл, причём очень сильный. Нужно не бояться им пользоваться, потому что он обычно более явный, чем что-то там в рантайме
AB
Ну, у нас же есть компайл, причём очень сильный. Нужно не бояться им пользоваться, потому что он обычно более явный, чем что-то там в рантайме
да не хочу я в компайл-тайме этим заморачиваться, я это отлаживать задолбаюсь
AB
спасибо, у меня уже есть один кодоген в проекте, трифт пинтерестовский, и что ты думаешь? без записи метаинформации для доступа в рантайме, с одной сериализацией/десериализацией он гораздо менее полезен, чем мог бы
AB
да, он быстрее эрлангового трифта, в котором сериализация работает как интерпретатор метаинформации, но на эрланговом трифте я могу делать, например, валидацию данных, или какие-то производные от этой метаинформации(generic thrift <-> json codec), а в эликсирном - нет, потому что там генерится только код кодека, без этих описаний
AB
и фактически мы вернулись к старому разговору - данные vs кодогенерация, и я остаюсь на той же позиции - данные первичны, а кодогенерация должна делаться уже на их основе.
ML
может быть, да.
я припоминаю, вы что-то упоминали про словари тэгов, определяющих как десериализовывать поле сообщения.
я припоминаю, вы что-то упоминали про словари тэгов, определяющих как десериализовывать поле сообщения.
ага. Определена куча структур и ещё одна, которая CHOICE.
Она сама проставит нужный тег
Она сама проставит нужный тег
AB
ага. Определена куча структур и ещё одна, которая CHOICE.
Она сама проставит нужный тег
Она сама проставит нужный тег
не, там что-то более замороченно было, information classes, чтоли.
но можно и эту аналогию засчитать, просто я этот choice хочу собрать с кода приложения.
но можно и эту аналогию засчитать, просто я этот choice хочу собрать с кода приложения.
ML
не, там что-то более замороченно было, information classes, чтоли.
но можно и эту аналогию засчитать, просто я этот choice хочу собрать с кода приложения.
но можно и эту аналогию засчитать, просто я этот choice хочу собрать с кода приложения.
например, это очень изящно делается в лиспе, когда ты парсишь код и по нему что-то кодогенеришь
ŹR
Так и причём тут консолидация, пусть модули со структурами явно у себя вызывают какой-нибудь макрос, который посылает имплементацию в какой-нибудь процесс, который дожидается конца компиляции и потом генерирует код в
__before_compile__ твоего модуля-десериализатораТак нельзя сделать потому что не факт что нужный модуль будет скомпирован последним
LL
Так нельзя сделать потому что не факт что нужный модуль будет скомпирован последним
Так нужный модуль будет висеть с
call в before_compileAB
вообще, https://hexdocs.pm/mix/Mix.Task.Compiler.html#after_compiler/2 удивительная функция.
про нее в интернетах есть три упоминания - анонс elixir 1.10, дока, и проект telemetria на гитхабе, и ни одно из них не описывает, в общем, в каких условиях она может не работать
про нее в интернетах есть три упоминания - анонс elixir 1.10, дока, и проект telemetria на гитхабе, и ни одно из них не описывает, в общем, в каких условиях она может не работать
короче, это абсолютно провальная зацепка, потому что
1 - у меня этот коллбэк просто не работает, откуда бы я его не регистрировал
2 - он вызывается в compile.all, а compile.protocol работает уже после него
1 - у меня этот коллбэк просто не работает, откуда бы я его не регистрировал
2 - он вызывается в compile.all, а compile.protocol работает уже после него
AB
видимо всё же враппер вокруг recompile в .iex.exs
ŹR
Так нужный модуль будет висеть с
call в before_compileТы уверен что before_compile всех модулей произойдёт раньше чем полностью скомпилируется другой модуль?
ŹR
Ну то есть что не может один из модулей полностью скомпилироваться так, что другой ещё даже не начнёт?
ŹR
Если бы он от него зависел - тогда да. Но тут идёт все в другом направлении
ŹR
Я думаю что если бы это работало - не было бы смысла в консолидации протоколов.
ŹR
Их можно было бы гарантированно консолидировать встроенными средствами
ŹR
Вообще, если в эликсир добавить кастомную консолидацию - получились бы рельсы
LL
Ты уверен что before_compile всех модулей произойдёт раньше чем полностью скомпилируется другой модуль?
Не, у меня модули-структуры просто посылают что-то на процесс (а если его не существует, то создают с таким именем), а потом, в модуле-десериализаторе на хуке
А процесс ответит тогда, когда поймёт что скомпилированы все модули кроме модуля десериализатора
__before_compile__ ждать ответа от процессаА процесс ответит тогда, когда поймёт что скомпилированы все модули кроме модуля десериализатора