Сообщение Re[2]: JSON vs BSON: очередное торжество больного воображени от 29.11.2022 18:54
Изменено 29.11.2022 18:55 vdimas
Re[2]: JSON vs BSON: очередное торжество больного воображения и
Здравствуйте, swame, Вы писали:
S>Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам
S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
Можно было обыграть нестрогим JSON (это который в синтаксисе Java Script, где названия полей всегда латинница, числа без кавычек.
Тогда твой пример будет таким:
То бишь, сохраняется структурированность описания, но выходит чуть компактней.
В синтаксисе JS порой намного удобней, бо можно вводить промежуточные значения:
Что в развесистых описаниях резко повышает читабельность.
Хотя, если уж самим писать парсер, то я бы убрал синтаксическую избыточность:
Или с форматированием:
Т.к. оно и без лишних знаков препинания парсится всё тем же LR(1) парсером, который можно написать на коленке за вечер безо-всяких генераторов парсеров, т.к. просмотр всего на один шаг вперёд, то бишь каждый раз происходит простое ветвление на текущем токене.
S>Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам
S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
Можно было обыграть нестрогим JSON (это который в синтаксисе Java Script, где названия полей всегда латинница, числа без кавычек.
Тогда твой пример будет таким:
{
Table: {
Name: "Analogs",
colCount: 7,
rowCount: 10001
},
Columns: ["ID","Name","Path","Tag","Min","Max","Value"],
CanWrite: [1,1,1,1,1,1,1],
Rows: [
[0,"analog_0",0,0,10,90,18],
...
[10000,"analog_10000",100,10000,10,90,10]
]
}
То бишь, сохраняется структурированность описания, но выходит чуть компактней.
В синтаксисе JS порой намного удобней, бо можно вводить промежуточные значения:
part1 = {
A: 1,
B: 0
};
part2 = { C: "X", D: ["Y", "Z"] };
config = { L: part1, M: part2 };
Что в развесистых описаниях резко повышает читабельность.
Хотя, если уж самим писать парсер, то я бы убрал синтаксическую избыточность:
part1: { A: 1 B: 0 }
part2: { C: "X" D: ["Y" "Z"] }
config: { L: part1 M: part2 }
Или с форматированием:
part1: {
A: 1
B: 0
}
part2: {
C: "X"
D: [
"Y"
"Z"
]
}
config: {
L: part1
M: part2
}
Т.к. оно и без лишних знаков препинания парсится всё тем же LR(1) парсером, который можно написать на коленке за вечер безо-всяких генераторов парсеров, т.к. просмотр всего на один шаг вперёд, то бишь каждый раз происходит простое ветвление на текущем токене.
Re[2]: JSON vs BSON: очередное торжество больного воображени
Здравствуйте, swame, Вы писали:
S>Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам
S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
Можно было обыграть нестрогим JSON (это который в синтаксисе Java Script, где названия полей всегда латинница, числа без кавычек).
Тогда твой пример будет таким:
То бишь, сохраняется структурированность описания, но выходит чуть компактней.
В синтаксисе JS порой намного удобней, бо можно вводить промежуточные значения:
Что в развесистых описаниях резко повышает читабельность.
Хотя, если уж самим писать парсер, то я бы убрал синтаксическую избыточность:
Или с форматированием:
Т.к. оно и без лишних знаков препинания парсится всё тем же LR(1) парсером, который можно написать на коленке за вечер безо-всяких генераторов парсеров, т.к. просмотр всего на один шаг вперёд, то бишь каждый раз происходит простое ветвление на текущем токене.
S>Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам
S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
Можно было обыграть нестрогим JSON (это который в синтаксисе Java Script, где названия полей всегда латинница, числа без кавычек).
Тогда твой пример будет таким:
{
Table: {
Name: "Analogs",
colCount: 7,
rowCount: 10001
},
Columns: ["ID","Name","Path","Tag","Min","Max","Value"],
CanWrite: [1,1,1,1,1,1,1],
Rows: [
[0,"analog_0",0,0,10,90,18],
...
[10000,"analog_10000",100,10000,10,90,10]
]
}
То бишь, сохраняется структурированность описания, но выходит чуть компактней.
В синтаксисе JS порой намного удобней, бо можно вводить промежуточные значения:
part1 = {
A: 1,
B: 0
};
part2 = { C: "X", D: ["Y", "Z"] };
config = { L: part1, M: part2 };
Что в развесистых описаниях резко повышает читабельность.
Хотя, если уж самим писать парсер, то я бы убрал синтаксическую избыточность:
part1: { A: 1 B: 0 }
part2: { C: "X" D: ["Y" "Z"] }
config: { L: part1 M: part2 }
Или с форматированием:
part1: {
A: 1
B: 0
}
part2: {
C: "X"
D: [
"Y"
"Z"
]
}
config: {
L: part1
M: part2
}
Т.к. оно и без лишних знаков препинания парсится всё тем же LR(1) парсером, который можно написать на коленке за вечер безо-всяких генераторов парсеров, т.к. просмотр всего на один шаг вперёд, то бишь каждый раз происходит простое ветвление на текущем токене.