От add - ожидаешь, что он сохранит физ.смысл = сложение/слияние ключей. Картинки прилагаются.

andylars 07.06.2016 00:28 / 07.06.2016 00:50

Первоначальная идея G_Z "прокачать" уже сущ.add, чем делать более скупой replace, мысль - ясна.

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

Скрещивать add сразу со вставкой, форсированно предлагая думать о "вставке перед" - как-то неочевидно, и заморочено. И что в таком разе, означает предложенный тут же put...

Либо я уже потерял угол восприятия, или происходит что-то не то.
Чтобы не писать "портянки", прилагаю умозрительные схемы всех основных сценариев для нового add, глазами "пользователя", с его изначальной "физикой" - слияния.

Привожу умозрительные картинки для ^хеш.add[хеш-слагаемое]
1) Сложение по ключу (стандартное)
2) Сложение по индексу(1)
3) Сложение по индексу[last]
4) Сложение по индексу[last] пачка
5) Сложение по индексу(1)+коллизия (усушка ключей)

Соответственно, изменения ключей в том же месте по индексу - происходит при работе в режиме индекса (с указанием $.at), в ином случае, будет работа по ключу (как обычно).

Для вставки под-хеша в хеш, с указанием before/after (key/index) всё же просится отдельный метод, а-ля insert или лучше extend (если продолжать в стиле работы со множествами: union,intersection,add,sub)

P.S.: И что тогда такое put, кстати?

---