Обсуждение дальше + Disclaimer: в вопросе именований, названия методов, опций и подачи - я полностью полагаюсь на "парсерную мафию" :)

andylars 04.06.2016 13:04 / 04.06.2016 13:15

Disclaimer:
Обозначу, что именно в вопросе именований и "подачи" - я вообще целиком и полностью полагаюсь на "парсерную мафию", объявившуюся в треде :)
Предложенные названия и способ подачи аргументов/опций, просто для умозрительного восприятия. Я обсуждаю только модель и функции - за названия не держусь от слова - "совсем".

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

Продолжим формализацию дальше:
В контексте этой ветки формализации, будем опираться на факт, что раскройка первой скомканой формализации - на принципиальные два "полушария"-механик по работе с элементами хеша:
A) изменение хеша "поверх" - (overlaying)
B) вставка в хеш "между" - (insertion)

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

Отсекая от камня по методу "прогрессивного джипега" :) и в контексте этой раскройки отдельно, крутим дальше:

Механика "overlaying"
Имеем сл.принципиальный момент: что мы хотим с позиции строгости?
- строгий инструмент "изменение" = только сущ.элементы хеша.
- мягкий инструмент "наплыв" = изменение/добавление если элемент не существует.

Строгий, очевидно, напрашивается на а-ля replace с +/-(объектная адресация до ключа перед методом) типа ^hash.key.replace[newkey;newvalue]

Мягкий = один в один повторяет механику питоновского update для OrderedDict, то есть изменяет элемент или добавляет если такого нет (это ровно то же самое, что и ранний put с overwrite)

update - семантически подразумевает, как "обновление" сущ.ключа, так и обновление самого "хеша" (через появления новых ключей), и может доиграть строгий replace, путем какой-то опции (а-ля strict/overwrite).


Опять же, в парсеровской реальности предложеный replace - умеет заменять не только элемент, но и попутно можно поменять только ключ или значение, не испортив подачу.
Поэтому, пока кажется, что replace (с возвратом true/false) явно нужнее.

---