Тот случай, когда это вообще нередкий атомарный кейс.

dimolezhkin 28.07.2021 14:30 / 28.07.2021 14:56

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

Т.е. работа с рядами, что основы конструкции многих популярных языков.
(для наглядой аналогии, чтобы не было вопросов, что я придумываю эфемерные потребности - то любой кейс, для которого нужно вот это https://docs.python.org/2/tutorial/datastructures.html#more-on-lists)

Никто же не скажет - зачем Lists и методы insert и remove - Питону?
И никто не скажет, что если "там" это пригодилось (и язык пригоден для веба), то в в коде на Парсере внезапно такие задачи должны раствориться?


Для работ с рядами - в Парсере нет Array, нет List, нет tuples (чтобы приготовить из списка тюплов - таблицу).

Потому, что есть уже вкусные Table и Hash-с-сохранением-порядка, которые вроде как перекрывают упомянутые структуры слихвой, но родовая травма (отстуствия insert у hash и delete у table) - никак красиво не убирается.

Чтобы мне поддерживать упорядоченный список значений, и производить операции с ним, мне надо:

- или использовать table и "19 лет подряд удалять записи фулскан-поиском"/конвертацией в хеш и обратно на каждый чих.

- или воротить на самом Парсере класс с "прокладкой" в виде нумерации на хешах, что явно ни про эффективность, ни про выразительность, ни про "использование нативных вещей" вместо изобретения велосипеда, вида:

$ordered_hash[
  $.1[ $.key[value] ]
  $.2[ $.key[value] ]
]

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

Тут даже намного больше проблем, мгновенный доступ по ключу - тоже убивается нафиг, и надо будет перебрать все 1.key 2.key 3.key (которые уже кстати могут стать и неуникальными).

Не, может это как-то проще делается в Парсере - тогда ткните носом, покажите, как вставлять и удалять по оффсету из хеша.

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

И хеши в разы удобнее, т.к. значением может быть любой объект. А после того, как хешу дали и sort и select (!) - и подавно. После таких неожиданно щедрых методов table можно прикопать по сути. Но оставить хеш без insert - это прям изуверство :)

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

---