Я об этом и говорил: это моя логическая позиция (дизайн модели), а для оформления рабочего синтаксиса - нет такого опыта в Парсер.

andylars 05.06.2016 09:06 / 05.06.2016 09:58

На предложение MoKo "кто заикнулся тому и лопата в руки",
я честно покрутил модель парсерного хеша, пройдя 3 итерации осмысления.

Заглянул для опоры в опыт сообщества Python 2.x/3.x, потыкал как он обрабатывает коллизиции (на удивление - ничего нового, а практически так же, как и было предложено "от бедра": либо исключение, либо strict=True/False).

Поэтому, думается, что это наиболее лаконичная и при этом интуитивно-понятная модель (из числа предложенных в треде), но закрывающая, при этом, всё по вставке/замене/переименованию элементов.

Все неявные моменты (при работе с индексом + ключом) сводятся к минимально-возможному числу = всего 1(одна), и при этом максимально очевидная коллизия (которая может даже опционально обработана по-разному).

При неоднократной попытке слепить другую модель (без осознанной раскройки по over/insert), лично я получал только бОльшее кол-во коллизий и неявных поведений, с растущим зоопарком опций или кол-вом методов. И пример предложенного add,rename и т.п. - только доказывает эту гипотезу.

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

В практическом смысле, это означает, что каждый из двух логических методов - прототипов (replace/insert), можно как угодно переименовать, подать по синтаксису/аргументам, и даже раздробить на методы, при условии не смешивать логические методы-прототипы между собой.

Так, что кругов нет - я прикатился к предложенному прототипу, требующему должного оформления, либо пересмотра самого прототипа, если есть более весомые контраргументы.

---