Здравствуйте, B0FEE664, Вы писали:

BFE> R>И ни слова о типах.

BFE> Ну не совсем:
...

Тут речь не о типах, а о представлении данных на физическом уровне (это следует из контекста вычисления адресов элементов по индексу).

BFE> Если array может хранить различные элементы, то чем он тогда отличается кортежа?

У кортежей нет возможности индексации (цифровые имена членов кортежа это не индексный доступ), у массива это ключевая особенность.

Здравствуйте, B0FEE664, Вы писали:

BFE>·>Токенайзер этим занимается. Иначе, например, \" он не сможет правильно на токены побить.
BFE>Что мешает токенайзеру пропустить все пары \" до одиночного символа " ?
json спека? \", \u и прочие \n определены одинаково. Почему токенайзер каким-то escape-последовательностям отдавать предпочтение — неясно.

Здравствуйте, ·, Вы писали:

·>Токенайзер выдаёт линейный поток токенов, в случае json это будет плоский список {, "field1", :, "value", "field2", :, 42, }.
BFE>>·>Токенайзер этим занимается. Иначе, например, \" он не сможет правильно на токены побить.
BFE>>Что мешает токенайзеру пропустить все пары \" до одиночного символа " ?
·>json спека? \", \u и прочие \n определены одинаково. Почему токенайзер каким-то escape-последовательностям отдавать предпочтение — неясно.
Хорошо. Тогда не понятно, почему escape-последовоательность не отдельный токен:
Т.е. почему для Json'а ["\u00312345"] токенайзер выдаст: [, "12345", ], а не [, ", \u0031, 2345, ", ]

Здравствуйте, B0FEE664, Вы писали:

BFE>Хорошо. Тогда не понятно, почему escape-последовоательность не отдельный токен:
BFE>Т.е. почему для Json'а ["\u00312345"] токенайзер выдаст: [, "12345", ], а не [, ", \u0031, 2345, ", ]
Ровно по тому же, почему для ["x\"y"] выдаст [, x"y, ], а не что-то другое (даже не знаю что тут можно придумать чтобы имело хоть какой-то смысл). Т.е. бэкслеш обрабатывается одинаково той же частью кода, вне зависимости от того что после этого бэкслеша стоит.

Здравствуйте, ·, Вы писали:

BFE>>Хорошо. Тогда не понятно, почему escape-последовоательность не отдельный токен:
BFE>>Т.е. почему для Json'а ["\u00312345"] токенайзер выдаст: [, "12345", ], а не [, ", \u0031, 2345, ", ]
·>Ровно по тому же, почему для ["x\"y"] выдаст [, x"y, ], а не что-то другое (даже не знаю что тут можно придумать чтобы имело хоть какой-то смысл).
А ведь смысл-то есть, например:

= is a special javascript character that must be escaped to unicode in JSON so that a string literal can be embedded in XHTML without further escaping.

Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?

·>Т.е. бэкслеш обрабатывается одинаково той же частью кода, вне зависимости от того что после этого бэкслеша стоит.
Может так, а может и нет. От задачи зависит.
Так что CreatorCray в чём-то прав с точки зрения практики, но совершенно не понимает в идеологии.

Здравствуйте, rudzuk, Вы писали:

R>Тут речь не о типах, а о представлении данных на физическом уровне (это следует из контекста вычисления адресов элементов по индексу).
Ну допустим.
Много вы знаете языков поддерживающих массивы разнотипных элементов? В каких задачах это используется?

BFE>> Если array может хранить различные элементы, то чем он тогда отличается кортежа?
R>У кортежей нет возможности индексации (цифровые имена членов кортежа это не индексный доступ), у массива это ключевая особенность.
— а что же это? К тому же по вашей же ссылке для массива не обязательно иметь индекс, достаточно иметь ключ:

In computer science, an array is a data structure consisting of a collection of elements (values or variables), each identified by at least one array index or key.

Здравствуйте, B0FEE664, Вы писали:

BFE>А ведь смысл-то есть, например:
BFE>

BFE>= is a special javascript character that must be escaped to unicode in JSON so that a string literal can be embedded in XHTML without further escaping.

Это откуда за цитата и о чём?

BFE>Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?
Чтобы правильно и однозначно разбить поток символов на токены.

BFE>·>Т.е. бэкслеш обрабатывается одинаково той же частью кода, вне зависимости от того что после этого бэкслеша стоит.
BFE>Может так, а может и нет. От задачи зависит.
Ну можно натянуть, что если у тебя не просто json-либа, а, скажем, умный текстовый редактор, который должен как-то особо обрабатывать json, то наверное да.

Здравствуйте, B0FEE664, Вы писали:

BFE>Ну допустим.
BFE>Много вы знаете языков поддерживающих массивы разнотипных элементов? В каких задачах это используется?
Разнотипные элементы ты сам придумал. Тип один — JsonValue или вроде того. И такие массивы object[] поддерживаются в java/c# и т.п.

BFE>>> Если array может хранить различные элементы, то чем он тогда отличается кортежа?
R>>У кортежей нет возможности индексации (цифровые имена членов кортежа это не индексный доступ), у массива это ключевая особенность.
BFE>- а что же это? К тому же по вашей же ссылке для массива не обязательно иметь индекс, достаточно иметь ключ:
BFE>

BFE>In computer science, an array is a data structure consisting of a collection of elements (values or variables), each identified by at least one array index or key.

Если ключ, то это так называемый associative array (синоним мапы или словаря).

Здравствуйте, B0FEE664, Вы писали:

BFE> Много вы знаете языков поддерживающих массивы разнотипных элементов? В каких задачах это используется?

Я приводил пример с вариантом и базовым типом объектов, там элементы имеют один тип, но содержат данные разных типов. Например, в паскале мы можем передать массив элементов разного типа (на самом деле нет, но да) в параметре:

function Format(const Format : string; const Params : array of const);
...

Format('%d, %s, %f', [1, '2', 3.0]);

Достаточно распространненная функция

BFE> BFE>> Если array может хранить различные элементы, то чем он тогда отличается кортежа?

BFE> R>У кортежей нет возможности индексации (цифровые имена членов кортежа это не индексный доступ), у массива это ключевая особенность.

BFE> — а что же это?

Это условное именование элементов. Конечно, в каком-нибудь петухоне с динамической типизацией, элементы кортежа могут иметь индексный доступ, но именно благодаря дин. типизации. В общем, смысл в том, что в кортеже размеры элементов могут быть разными, поэтому индекс к ним можно прикрутить только "сбоку" (например, выразив кортеж через более сложную структуру), в массиве же их размер должен быть одинаковым, поэтому индексирование является естественным.

BFE> К тому же по вашей же ссылке для массива не обязательно иметь индекс, достаточно иметь ключ:

BFE> In computer science, an array is a data structure consisting of a collection of elements (values or variables), each identified by at least one array index or key.

Это если говорить об интерфейсе "массив". Тогда да, в качестве индекса может выступать и ключ, а под капотом там может быть, например, хеш-таблица, и правильно это будет называться ассоциативным массивом. Если же говорить, о массиве, как базовой структуре, то это просто кусок памяти с индексным доступом.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, swame, Вы писали:

S>> Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам
S>>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
S>>По сути, возврат к тому же CSV, но в одном файле можно описать несколько структур разного формата.
·>Это извращение какое-то not invented here. Осталось написать к этому чуду парсеры-форматтеры на всех ЯП, интегрировать синтаксис во все IDE и всякие тулзы — вот тогда норм.

Парсеры — форматтеры писать не надо, потому что это по формату обычный JSON, но сформированный с учетом определенных соглашений.
Но он ориентирован на более скоростную и экономичную обработку, чем при обычном использовании JSON высокоуровневыми обертками.
И требует несколько (ненамного) больше писания кода для использования. И понимать, что под капотом при этом.

S>>По скорости когда- то мерял, сериализация / десериализация по скорости в районе 400 Mb/c.
S>>Но без всяких reflection.
S>>От идеи бинарного формата давно отказался, по причинам , которые уже объяснили.
·>Переставь кавычки и получится простейший json.

Это и так json

·>

S>>    "CanWrite": [1,1,1,1,1,1,1],
S>>    "Rows": [
S>>        [0,"analog_0",0,0,10,90,18],
S>>        [1,"analog_1",0,1,10,90,97],
S>>}
·>

Здравствуйте, swame, Вы писали:

S>·>Это извращение какое-то not invented here. Осталось написать к этому чуду парсеры-форматтеры на всех ЯП, интегрировать синтаксис во все IDE и всякие тулзы — вот тогда норм.
S>Парсеры — форматтеры писать не надо, потому что это по формату обычный JSON, но сформированный с учетом определенных соглашений.
И кто определял эти соглашения? Где стандарт, поддержка этих соглашений в IDE и в разных либах?

S>Но он ориентирован на более скоростную и экономичную обработку, чем при обычном использовании JSON высокоуровневыми обертками.
Но ведь тебе всё равно придётся где-то парсить содержимое твоих строк. Ты просто перенёс логику из json-парсера наружу. И т.к. как парсер стал делать меньше работы, то и не удивительно замеры показали типа повысилась скорость. Но работа-то никуда не делась... просто ты исключил её из замеров.

Хотя возможно у тебя какой-то корявый медленный json-парсер, который лень фиксить или заменить, и проще обойти вот такими строками.

S>·>Переставь кавычки и получится простейший json.
S>Это и так json
У тебя значения в json требуют дополнительного парсинга. Вот в такой строке "0,analog_0,0,0,10,90,18" — могут быть хитрости. Например, что если значение нужно будет содержать запятую вроде analog_0,1?

Здравствуйте, ·, Вы писали:

·>Здравствуйте, swame, Вы писали:

S>>·>Это извращение какое-то not invented here. Осталось написать к этому чуду парсеры-форматтеры на всех ЯП, интегрировать синтаксис во все IDE и всякие тулзы — вот тогда норм.
S>>Парсеры — форматтеры писать не надо, потому что это по формату обычный JSON, но сформированный с учетом определенных соглашений.
·>И кто определял эти соглашения? Где стандарт, поддержка этих соглашений в IDE и в разных либах?

Определил я на уровне своей компании. На мировой стандарт не претендую.

S>>Но он ориентирован на более скоростную и экономичную обработку, чем при обычном использовании JSON высокоуровневыми обертками.
·>Но ведь тебе всё равно придётся где-то парсить содержимое твоих строк. Ты просто перенёс код из парсера наружу. И т.к. как парсер стал делать меньше работы, то и не удивительно замеры показали типа повысилась скорость. Но работа-то никуда не делась... просто ты исключил её из замеров.

Работы меньше. Размер файла меньше раза в 2-3.
Число узлов в DOM дереве при парсинге меньше на порядок. Соответственно и занимаемая память.
При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.
Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.

·>Хотя возможно у тебя какой-то корявый медленный json-парсер, который лень фиксить или заменить, и проще обойти вот такими строками.

Обычный, хороший парсер, просто, условно, вместо обработки миллиона атрибутов в секунду я обработаю 3 миллиона.
У меня объемы очень большие, лишняя скорость не помешает.

S>>·>Переставь кавычки и получится простейший json.
S>>Это и так json
·>У тебя значения в json требуют дополнительного парсинга. Вот в такой строке "0,analog_0,0,0,10,90,18" — могут быть хитрости. Например, что если значение нужно будет содержать запятую вроде analog_0,1?

Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.

Здравствуйте, swame, Вы писали:

S>>>Но он ориентирован на более скоростную и экономичную обработку, чем при обычном использовании JSON высокоуровневыми обертками.
S>·>Но ведь тебе всё равно придётся где-то парсить содержимое твоих строк. Ты просто перенёс код из парсера наружу. И т.к. как парсер стал делать меньше работы, то и не удивительно замеры показали типа повысилась скорость. Но работа-то никуда не делась... просто ты исключил её из замеров.
S>Работы меньше. Размер файла меньше раза в 2-3.
Непонятно засчёт чего. "0,analog_0,0,0,10,90,18" практически такого же размера как и [0,"analog_0",0,0,10,90,18]. Ну и зипануть можно. И разницы в микроскоп не заметишь.

S>Число узлов в DOM дереве при парсинге меньше на порядок. Соответственно и занимаемая память.
Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...

S>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.
S>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).

S>·>Хотя возможно у тебя какой-то корявый медленный json-парсер, который лень фиксить или заменить, и проще обойти вот такими строками.
S>Обычный, хороший парсер, просто, условно, вместо обработки миллиона атрибутов в секунду я обработаю 3 миллиона.
...или вообще поди в память не надо складывать, а можно обрабатывать поточно на порядок быстрее.

S>У меня объемы очень большие, лишняя скорость не помешает.
С DOM хорошей скорости вообще практически никак не обеспечить.

S>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.
Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.

Здравствуйте, B0FEE664, Вы писали:

BFE>А вот и не подерётесь.

Автор: ·
Дата: 16.03.23

Что сказать то хотел?

Здравствуйте, B0FEE664, Вы писали:

BFE>Так что CreatorCray в чём-то прав с точки зрения практики, но совершенно не понимает в идеологии.

Идеология — зло.
Ибо есть теория а есть реальный мир. И уж слишком часто то, что красиво звучит в теории, на практике либо сразу лежит трупом либо лютый багодром, где "вша чОрная, вша жОлтая, и усеницы" (С)

Здравствуйте, ·, Вы писали:

·>Здравствуйте, swame, Вы писали:

·>Непонятно засчёт чего. "0,analog_0,0,0,10,90,18" практически такого же размера как и [0,"analog_0",0,0,10,90,18]. Ну и зипануть можно. И разницы в микроскоп не заметишь.

В файле разницы и правда не заметишь, а в памяти DOM разница будет на порядок.

Но я сравниваю не с этим а с обычным json
ID="0"
Name="analog_0"
Path=""
Tag="0"
Min="10"
Max="90"
Average="55"
Value="18"

·>Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...

Я не против событийного, когда понадобится по скоростным характеристикам, но сложность работы с ним будет точно не меньше , чем с моим форматом.

S>>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.
S>>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
·>Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).

Да, я положу в массив, который будет существовать только на момент парсинга, а парсер в коллекцию Key/Value, индексированную или нет в зависимсоти от реалицации, и занимающую кучу памяти, и будут они все занимать память одновременно до уничтожения DOM

·>С DOM хорошей скорости вообще практически никак не обеспечить.

Пока хватает без лищней сложности, перестанет хватать — перейду на поточный.
К тому же иногда DOM намного удобней, например для внесения точечных изменений — распарсил все, нашел узел, изменил, сохранил обратно.

S>>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.
·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.

Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов в строку с разделителями,
подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.
Даже на то, чтобы подобрать подходящий набор параметров для парсера в готовой либе может уйти прилично времени.

Здравствуйте, swame, Вы писали:

S>·>Непонятно засчёт чего. "0,analog_0,0,0,10,90,18" практически такого же размера как и [0,"analog_0",0,0,10,90,18]. Ну и зипануть можно. И разницы в микроскоп не заметишь.
S>В файле разницы и правда не заметишь, а в памяти DOM разница будет на порядок.
S>Но я сравниваю не с этим а с обычным json
Зачем?! Чтоб страшнее было?

S>·>Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...
S>Я не против событийного, когда понадобится по скоростным характеристикам, но сложность работы с ним будет точно не меньше , чем с моим форматом.
Уж точно не больше. Не бином ньютона, для твоего конкретной схемы json пишется за пол дня с 100% покрытием тестами.

S>>>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.
S>>>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
S>·>Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).
S>Да, я положу в массив, который будет существовать только на момент парсинга, а парсер в коллекцию Key/Value, индексированную или нет в зависимсоти от реалицации, и занимающую кучу памяти, и будут они все занимать память одновременно до уничтожения DOM
Мде. Костыль, короче.

S>·>С DOM хорошей скорости вообще практически никак не обеспечить.
S>Пока хватает без лищней сложности, перестанет хватать — перейду на поточный.
Ну раз ты начал изобретать свой формат, значит не хватало.

S>К тому же иногда DOM намного удобней, например для внесения точечных изменений — распарсил все, нашел узел, изменил, сохранил обратно.
Неясно с чего ты решил, что поточый обработчик будет почему-то сложнее.

S>>>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.
S>·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.
S>Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов в строку с разделителями,
S>подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.
S>Даже на то, чтобы подобрать подходящий набор параметров для парсера в готовой либе может уйти прилично времени.
Ясно, велосипед он свой, родной.

Здравствуйте, CreatorCray, Вы писали:

BFE>>А вот и не подерётесь.

Автор: ·
Дата: 16.03.23

CC>Что сказать то хотел?

Так кто должен строку конвертировать "код импорта" или токенайзер?

Здравствуйте, ·, Вы писали:

BFE>>А ведь смысл-то есть, например:
BFE>>

BFE>>= is a special javascript character that must be escaped to unicode in JSON so that a string literal can be embedded in XHTML without further escaping.

·>Это откуда за цитата и о чём?
С просторов интернета о том, что преобразовывать escape последовательности следует не всегда.

BFE>>Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?
·>Чтобы правильно и однозначно разбить поток символов на токены.
Для этого их достаточно распознать.

Здравствуйте, B0FEE664, Вы писали:

BFE>·>Это откуда за цитата и о чём?
BFE>С просторов интернета о том, что преобразовывать escape последовательности следует не всегда.
Это что к чему? Какое это имеет отношение к json и парсерам?

BFE>>>Т.е. если у нас есть что-то, что понимает escape-последовоательности, то зачем нам их декодировать?
BFE>·>Чтобы правильно и однозначно разбить поток символов на токены.
BFE>Для этого их достаточно распознать.
Чтобы их распознать, их надо фактически декодировать.