Re: Ответ - "взбалтывать но не смешивать" (c).

andylars 04.06.2016 20:23 / 04.06.2016 20:31

Ключ получит новое значение в новой позиции.

Ничоси.
Изобразить метод add (сложения) как "наложение" по индексу/ключу - я еще понимаю.
Разрешение коллизиции путем false или утилизации одноименного ключа при работе по индексу - тоже еще как-то понятно.

Но сделать из "наложения/сложения" - вставку со сдвигом ввниз? Причем при работе в режиме индекса...

Т.е. вот так у вас происходит:

^hash.add(0)[$.KeyC[valueC2]]

0: KeyA:ValueA  ->    0: KeyC:ValueC2
1: KeyB:ValueB  ->    1: KeyA:ValueA
2: KeyC:ValueC  ->    2: KeyB:ValueB

Мало того, что как я и писал старый элемент 2:KeyC:ValueC -"утилизировался", так еще и остальные индексы подвинулись. Это еще менее очевидное поведение, чем предполагалось.

И плюс вы пишите:

Вставляет он после указанной позиции. Add добавляет ключ после указанного индекса, не вместо.

Что-то на примере результата выше кажется совсем иначе, как заказали в index(0) - так и получили, плюс шифт всего вниз.

Мы добавляем ключи в хеш в указанную позицию.
Метод уже так работает, появится только указатель позиции.

На вскидку в самой модели - каша какая-то, хотя синтаксис и подача аргументов в методы - не в пример лучше.


Вывод "взбалтывать, но не смешивать":
Все же гипотеза (выше по треду) о том, что при прочих равных - априори надо разделять и не смешивать overlaying и insertion - механики, а сами их по отдельности можно взбалтывать, но смешивать между собой = ни-ни.

Абракадбра, которая образуется в случае если мы принебрегаем этим фактом - доказывается раз за разом.

Собственно: http://www.parser.ru/forum/?id=83129

Поэтому, оставлю на суд остальных, мне кажется это такая реализация с add, это как раз та "каша", которую я получил на 2-ой "формализации", и уже к 3-ей осознал наличие чёткой оси - наложение/вставка, при принебрежении которой модель будет неуклонно заползать в неочевидные поведения.

---