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

CS>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну да. В принципе любое дерево преобразовать в XPath DOM
CS>XPath DOM есть XML DOM как я понимаю.

Это есть любой DOM, который ты реализуешь. Можешь называть его как тебе нравится.

ВВ>>Так вот — XPath будет лучше и серьезно лучше.

CS>Преобразование JSON в XML DOM это потеря иноформации.
CS>JSON (как структура данных) имеет два типа коллекций: arrays и maps. Терминалы тоже типизированы — strings, boolean, numeric.
CS>XML DOM имеет только списки и unisex nodes.

XML DOM тут не причем. Речь идет о создании врапперов для объектов, чтобы по ним можно было исполнять запросы XPath (или чего-то *похожего* на XPath).

CS>Представление JSON предельно компактно в памяти:
CS>Скажем массив [1,2,3] это примерно 20 байт (5*sizeof(int)). В XML каждая node это как минимум 20 байт, так nodes здесь нужно 4.

Правда? 20 байт? А сколько байт уходит на хранение дополнительной информации о типе данных в динамическом-то языке? Смешно блин. Теперь мы начали память экономить.
Тот, кому нужно экономить память не пишет на интерпретируемом языке.

CS>Ты предлагаешь забавный и предельно дорогой способ удалять зубы.

Забавный способ — это пробежаться по всему дереву, вычислить все варианты запросов и добавить их в хэш-таблицу. Почему ты считаешь по-другому я не знаю.
А построение промежуточного представления для исполнения запросов — это как бы нормально. Притом что, повторюсь, это представление должно строиться лениво.

ВВ>>Наконец XPath — это привычная людям штука, с привычным синтаксисом.
CS>В JS/Ruby/Python use cases? Сомневаюсь.

А ты не сомневайся, а погугли на XPath to Objects, к примеру.

CS>Во всяком случае никто в здравом уме не занимается предобразованием, скажем в Python, структур данных в XPath
CS>чтобы сделать запрос на коллекцию. Чтобы потом получить из найденного DOM элемента восставновить искомый объект.
CS>Короче все что угодно, например тот же LINQ, но только не преобразование данных ЯП->XML->ЯП.
CS>Я знаю компании где за такие "решения" с работы выгоняют.

За хэш-таблицы то? Да, я тоже знаю.

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

CS>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Здравствуйте, c-smile, Вы писали:

ВВ>>Результат testTernary: "nope"
ВВ>>Результат testPM: "0;0;0"

CS>obj.x && obj.y && obj.z — проехали.

CS>Я тебе привел имплементацию такого варианта:
CS>obj.match {x:#exist, y:#exist, z:#exist }
CS>здесь проверяется наличие атрибута. Какого бы значения они не были.

ПМ позволяет пройти глубже, чем только один уровень.

Если у нас есть объект.

var Obj = {val,
  {
     val3,
     val4
  }
}

То ПМ позволит сделать и такое:

match Obj
  on {P1, {P2, _}} ...
  on {любая_другая_структура} ...

где первый кейс проверит структуру объекта, а потом присвоит P1=val и P2=val3

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

CS>>Я тебе привел имплементацию такого варианта:
CS>>obj.match {x:#exist, y:#exist, z:#exist }
CS>>здесь проверяется наличие атрибута. Какого бы значения они не были.

M>ПМ позволяет пройти глубже, чем только один уровень.

M>Если у нас есть объект.
M>

M>var Obj = {val,
M>  {
M>     val3,
M>     val4
M>  }
M>}
M>

M>То ПМ позволит сделать и такое:
M>

M>match Obj
M>  on {P1, {P2, _}} ...
M>  on {любая_другая_структура} ... 
M>

Это все тот же случай, т.е. не решает проблему.
on {P1, {P2, _}} это тест на структуру самого объекта и его содержимого. Но никак не пути самого объекта
отнсительно root.

На примере CSS селекторов:

То что вы называете PM это простые селекторы: attribute, type, class, id и пр. селекторы.
То что я сделал это type + child combinators селекторы.