"Не мы начали эту войну" (c) ибо ^хеш.at[first | last] - уже был и есть в Парсер, а ^хеш.foreach - давно убил "академический словарь".

andylars 03.06.2016 14:17

Cмесь ключей и индексов не нравится совершенно

- Cмешение индексов и ключей, началась с ^hash.at
- ^hash.at с наличия упорядоченности ключей
- упорядоченность ключей с потребности в foreach.

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

Если бы у нас был массив - то как и во многих языках - мы бы сами "женили список со словарем" и получали коллекции, очереди, упорядоченные словари. Но у нас есть только таблица, значения которой не могут быть ссылки на объекты, а только string.

Однако, это совершенно не значит, что структура данных, которую реализует теперешний hash - плохая, не_правильная, или не существует в природе.

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

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

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

У меня сейчас (и уже N лет как) есть хеши с числовыми ключами

О чем, я и говорю - выше. Практически можно и на массивах все было делать, остальное абстракции. Просто смысл иметь цифровые ключи, а потом их упорядочивать самому, а потом вы в эти цифровые ключи кладете еще и ключ Name?... Получается просто "самообман" и "надстройка", а всё то же самое, только руками и с накладными расходами.


3.last/first: отдельно касательно именования, я согласен, мне тоже не нравится такая "вивисекция" (я просто привел по аналогии, с тем, что уже было см.сабж). В таком разе, надо и в $hash.fields - тоже камушек метнуть.

Служебные имена (Built-in Objects), действительно, было бы разумнее обрамлять или хотя бы предварять, подчеркиванием, или двумя (по аналогии с Питоном),
то есть __last, __first и $hash.__fields - как минимум.


4. Сами вещи мне нравятся. Где это может пригодиться? collection.p в PF - это именно изобретение велосипеда, которого нет в Парсер. Но также у Парсера нет и стандартного массива чтобы доиграть свои структуры, а "нумерованые ключи" хеша, это просто костыль само по себе.

Докрученный hash - превратит его в OrderedDict, дающий по обратной совместимости и "коллекции" и "массивы" и "стеки", "очереди" - из коробки.

^hash.insert[__first]... - это вставка в вершину стека/очереди. last - соответственно в конец. Это базовые вещи таких структур и они нужны.

И раз уж исторически так сложилось, и ^hash.at(0) уже давно с нами - то не вижу ничего страшного доиграть его до доступа по номеру элемента. Ничего при этому не ломается - приведите пример, как это может сломаться? Оно по-определению не может, если будет состоять из двух/трех разных примитивов - сам по себе.

---