Определение «токена» при десериализации JSON - PullRequest
Новая
       45

Определение «токена» при десериализации JSON

0 голосов
/ 10 апреля 2020

Когда мы говорим о сериализации JSON, обычно существует определение «токенов». Например, Newtonsoft перечисляет их перечисление токенов здесь . . NET Core 3.1's System.Text.Json также использует их в виде JsonTokenType.

Что привлекает мое внимание, так это наличие токенов для String , но также для StartArray и EndArray. Это похоже на так называемую «ошибку класса» или несоответствие, если хотите. Некоторые ссылаются на текстовые строительные блоки, которые связывают объекты (StartArray, EndArray), тогда как другие ссылаются на объекты, ограниченные ими (String).

Я бы ожидал чтобы увидеть одно из следующих, но не сочетаний:

  1. StartArray, EndArray, StartString, EndString (границы).
  2. StartArray, EndArray, DoubleQuote (границы, где мы ценим тот факт, что начало и конец строки - это один и тот же символ).
  3. Array, String (ограниченные объекты).

Я предполагаю, что существуют практические причины для различия. Тем не менее, такая ошибка класса должна раздражать при создании различных слоев десериализатора. «Подождите, у меня есть текстовые строительные блоки здесь, или они уже были преобразованы в объекты, которые они express?» «Да, извините, немного и того, и другого».

Вот мои вопросы:

  1. Являются ли эти определения токенов вездесущими, или это a. NET артефакт?
  2. Какова причина или польза для смешивания этих двух понятий таким образом?
  3. Если бы нам пришлось назвать два разных понятия, как бы мы их назвали? (A, текстовые строительные блоки, которые связывают объекты, такие как DoubleQuote, ArrayStart и ArrayEnd, и B, объекты, ограниченные ими, такие как String и Array.)
  4. Так как у нас ArrayStart и ArrayEnd, почему нет ArraySeparator?
...