AS
в это фразе очень узкое представление о "данных", как мне показалось, используется
Да, данные в узком смысле
Size: a a a
2020 August 17
Oℕ
Т.е. даже данные в каком-то протобафе уже не входят в это определение
Oℕ
Потому что способ разбора данных существенно зависит от схемы
LO
Я сам xml люблю больше yaml, но при взгляде на xml у половины знакомых рвотный рефлекс
я предпочитаю проблемно-ориентированные языки.
можно поверх s-exp навернуть для простоты
можно поверх s-exp навернуть для простоты
Oℕ
Т.е. от описания типов, который не присутствует в виде тегов в самих данных
AA
Да, данные в узком смысле
ну вот бинарные данные могут иметь теги и их можно интерпретировать без метаинформации, а могут не иметь. это уже не данные будут?
AS
и я не вижу чем { regexp: ".*" } хуже !regexp ".*"
один хрен в парсере разбирать
один хрен в парсере разбирать
Ну, чисто технически ты можешь сделать соглашение, что в api любое поле удовлетворяющее
{ regexp: ".*" } будет парситься в регексп. В ямле это соглашение заимплаеноLO
Ну, чисто технически ты можешь сделать соглашение, что в api любое поле удовлетворяющее
{ regexp: ".*" } будет парситься в регексп. В ямле это соглашение заимплаенозаимплаено реалитзацией парсера
AS
заимплаено реалитзацией парсера
В этом случае да, все отлично работает, можно даже сделать соглашение, что надо писать
"@regexp": ".*. Это же все на уровне соглашений и реализаций парсера по умолчанию идетAS
В yaml в динамически типизированных языках ты просто отдаешь словарь с лямбдами и он этими лямбдами собирает нужные тебе типы
AS
Парсеров json с такими фишками не встречал
Oℕ
edn
AS
Ну и любой формат сводится в конечном итогде к соглашениям и реализациям парсера
LO
наконец то тип-тег срач в блах
Oℕ
Есть ещё расширенный жсон
Oℕ
с аннотациями
A
всё что угодно, лишь бы дхалл не юзать
AS
Это DSL монги?
Oℕ
всё что угодно, лишь бы дхалл не юзать
дхалл юзать для чего?
Oℕ
для коммуникации?