ع
Иначе получится рельса
😂👍
я опять не в тему, но мне в голову приходит сделать такое:
defimpl A, for: Map do
def parse(%{__tag__: smth}) do
struct(???)
end
def parse (%{} = map), do: map
end
Size: a a a
2021 March 03
AB
да, это в общем оно.
упрощая, вопрос в том, откуда брать аргумент для struct.
на деле там конечно еще добавление runtime-only полей, апгрейды старых версий, etc.
упрощая, вопрос в том, откуда брать аргумент для struct.
на деле там конечно еще добавление runtime-only полей, апгрейды старых версий, etc.
AD
да, это в общем оно.
упрощая, вопрос в том, откуда брать аргумент для struct.
на деле там конечно еще добавление runtime-only полей, апгрейды старых версий, etc.
упрощая, вопрос в том, откуда брать аргумент для struct.
на деле там конечно еще добавление runtime-only полей, апгрейды старых версий, etc.
ну ты выше вроде писал что из тег и берется, не?
AD
или проблема с тем чтобы распарсить тег
AB
ну ты выше вроде писал что из тег и берется, не?
да, и в тег вообще можно просто атом модуля структуры положить, но хочется дополнительный indirection, чтобы в случае чего код рефакторить нормально.
на этом моменте возникает табличка tag -> module. вообще, ее легко собрать с consolidated протокола, и положить в кэш, чтобы не делать лишних телодвижений.
вопрос начался с того, как этот кэш в режиме разработки обновлять.
на этом моменте возникает табличка tag -> module. вообще, ее легко собрать с consolidated протокола, и положить в кэш, чтобы не делать лишних телодвижений.
вопрос начался с того, как этот кэш в режиме разработки обновлять.
AB
вообще, https://hexdocs.pm/mix/Mix.Task.Compiler.html#after_compiler/2 удивительная функция.
про нее в интернетах есть три упоминания - анонс elixir 1.10, дока, и проект telemetria на гитхабе, и ни одно из них не описывает, в общем, в каких условиях она может не работать
про нее в интернетах есть три упоминания - анонс elixir 1.10, дока, и проект telemetria на гитхабе, и ни одно из них не описывает, в общем, в каких условиях она может не работать
LL
протокол сериализации с тегами.
типа,
типа,
%S{} -> %{__tag__: "#{S}", ...} обеспечивается самим протоколом, и отсутствие необходимости руками поддерживать таблицу tag -> (%{} -> %S{})Я правильно понял, что ты хочешь сериализовать структуры в данные так, чтобы при десериализации данные распаковывались обратно в те же структуры?
Если количество этих структур определено протоколом и конечно, то просто генерируй кейсы для функции декодирования в компайле
Если количество этих структур динамическое, то тогда что ты будешь делать когда при десериализации ты распакуешь несуществующую структуру?
Если количество этих структур определено протоколом и конечно, то просто генерируй кейсы для функции декодирования в компайле
Если количество этих структур динамическое, то тогда что ты будешь делать когда при десериализации ты распакуешь несуществующую структуру?
AB
Я правильно понял, что ты хочешь сериализовать структуры в данные так, чтобы при десериализации данные распаковывались обратно в те же структуры?
Если количество этих структур определено протоколом и конечно, то просто генерируй кейсы для функции декодирования в компайле
Если количество этих структур динамическое, то тогда что ты будешь делать когда при десериализации ты распакуешь несуществующую структуру?
Если количество этих структур определено протоколом и конечно, то просто генерируй кейсы для функции декодирования в компайле
Если количество этих структур динамическое, то тогда что ты будешь делать когда при десериализации ты распакуешь несуществующую структуру?
количество таких структур в скомпилированной версии статично.
хотелось, чтобы количество структур определялось протоколом, да, но не уверен, что реализации протокола можно перечислить в компайл-тайме - по-моему, консолидация идет уже после всей компиляции.
хотелось, чтобы количество структур определялось протоколом, да, но не уверен, что реализации протокола можно перечислить в компайл-тайме - по-моему, консолидация идет уже после всей компиляции.
ML
протокол сериализации с тегами.
типа,
типа,
%S{} -> %{__tag__: "#{S}", ...} обеспечивается самим протоколом, и отсутствие необходимости руками поддерживать таблицу tag -> (%{} -> %S{})вот как с asn
AB
вот как с asn
может быть, да.
я припоминаю, вы что-то упоминали про словари тэгов, определяющих как десериализовывать поле сообщения.
я припоминаю, вы что-то упоминали про словари тэгов, определяющих как десериализовывать поле сообщения.
LL
количество таких структур в скомпилированной версии статично.
хотелось, чтобы количество структур определялось протоколом, да, но не уверен, что реализации протокола можно перечислить в компайл-тайме - по-моему, консолидация идет уже после всей компиляции.
хотелось, чтобы количество структур определялось протоколом, да, но не уверен, что реализации протокола можно перечислить в компайл-тайме - по-моему, консолидация идет уже после всей компиляции.
Так и причём тут консолидация, пусть модули со структурами явно у себя вызывают какой-нибудь макрос, который посылает имплементацию в какой-нибудь процесс, который дожидается конца компиляции и потом генерирует код в
__before_compile__ твоего модуля-десериализатораAB
Так и причём тут консолидация, пусть модули со структурами явно у себя вызывают какой-нибудь макрос, который посылает имплементацию в какой-нибудь процесс, который дожидается конца компиляции и потом генерирует код в
__before_compile__ твоего модуля-десериализатораужс
AB
то есть, да, наверное можно и так
AB
но ведь есть консолидация протоколов, которая фактически делает то же самое уже
AB
думаю, если не получится абьюзить консолидацию, напишу explicit - лень заморачиваться
LL
но ведь есть консолидация протоколов, которая фактически делает то же самое уже
Так и ты хочешь какую-то странную вещь
Чтобы на этапе компиляции знать объекты, которые нужно десериализовывать в структуры
Обычно просто пишут свой компилятор, который вызывается после (или перед) эликсировским и парсит файлы с определениями объектов
Определать объекты в коде, да ещё и на
Чтобы на этапе компиляции знать объекты, которые нужно десериализовывать в структуры
Обычно просто пишут свой компилятор, который вызывается после (или перед) эликсировским и парсит файлы с определениями объектов
Определать объекты в коде, да ещё и на
elixir-е как-то странно. Лучше делать просто use MyProto, schema: "path/to/file.schema"AB
Так и ты хочешь какую-то странную вещь
Чтобы на этапе компиляции знать объекты, которые нужно десериализовывать в структуры
Обычно просто пишут свой компилятор, который вызывается после (или перед) эликсировским и парсит файлы с определениями объектов
Определать объекты в коде, да ещё и на
Чтобы на этапе компиляции знать объекты, которые нужно десериализовывать в структуры
Обычно просто пишут свой компилятор, который вызывается после (или перед) эликсировским и парсит файлы с определениями объектов
Определать объекты в коде, да ещё и на
elixir-е как-то странно. Лучше делать просто use MyProto, schema: "path/to/file.schema"не-не, я не хочу их знать на этапе компиляции, я хочу их знать в рантайме, и узнать их в рантайме просто(из консолидированного протокола).
LL
не-не, я не хочу их знать на этапе компиляции, я хочу их знать в рантайме, и узнать их в рантайме просто(из консолидированного протокола).
Но это же объекты протокола взаимодействия, а такие протоколы в рантайме не меняются
Поэтому ты их знаешь уже в компайле
Поэтому ты их знаешь уже в компайле
LL
И поэтому они должны явно присутствовать в скомпилированной программе
Всё остальное можно оставить интерпретируемым языкам
Всё остальное можно оставить интерпретируемым языкам
LL
Лучше всего, конечно, знать все эти объекты не в компайле, а ещё до написания кода, чтобы явно описать их сереализацию и десереализацию