Кажется я понял, в чем реальная причина рассинхрона, давайте разберемся тогда, что такое add и union. Кстати, получается даже интереснее.

andylars 07.06.2016 08:55 / 07.06.2016 09:53

Вот я привёл конкретную картинку, которая рисовалась у меня для add. Который я всегда воспринимал, как операцию (сложения/слияние двух множеств), и в рамках обсуждения только дорисовал то поведение, которое кажется интуитивным при указании индекса:

http://s33.postimg.org/vffb8663z/p3_hash_add_2.png

Может я просто всегда ошибался насчет того, что такое add? Мне интутивно казалось, что это фактически зеркальная операция со множествами, по отношению к union - обе они про "слиянии" множеств.

Но union не перетирает старые ключи, а add наоборот перетирает. Фактически это выглядит как сляние множеств, но с правилом overwrite:true/false

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

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

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

Поэтому, при работе по индексу (режим рядов). Должно работать правило: сначала работаем как с массивом (рядом), а потом разрешаем коллизии имен ключей (множеств).

И вообще - органически прилежно, тогда всем методам работы со множествами / рядами (хеш+хеш), добавить работу с index.

sub + index = дает нам адресное удаление по индексу, в том числе пачками.
union/add + index = дает наложение рядов с overwrite или нет.

extend/insert + index = вставка под-ряда в ряд (будет ли давать др.результат с учетом разрешения коллизиции по именам ключей, т.е. на этапе работы со множеством, после отработки этапа работы с рядом)

---