Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2005-05-01 15:21:39 ЛС | профиль | цитата
Гость,
1) Говорить о том, что сегодня лежит в SHA-файле для случая ссылок сегодня преждевременно, поскольку сегодняшнее содержание просто ошибочно.
2) Я не считаю, что вход во внутреннюю схему мультика через два промежуточных элемента зто самое рациональное решение. Да и понятие рациональности бывает разное (объем кодов и быстродействие - разные критерии). Но так сделал Автор (который, по моему пониманию, имеет право на иное, отличное от нашего, понимание рациональности), и НЕ это является препятствием для введения новых возможностей в среду. К тому же EditMulti является интерфейсным элементом и для другого типа контейнеров.
3) Именно так сегодня и делается для мультиков де-факто. Создание ссылки в схеме приводит к появлению MultiElementEx (который является интерфейсным между остальной схемой и EditMultiEx), у которого свое поле FChild, но (в отличии от копии :! поле FOnCreate указывает на уже существующий класс. А в случае копии - это был (и есть, впрочем) каждый раз новый класс.
4) Говоря про интерфейсные вещи, не следует забывать и вопросы совместимости. Поэтому, менять смысл сегодняшнего копирования - это не совсем приемлимо, ИМХО. Тем более, что копирование - не самая бесполезная операция:
Просто, иногда и копирование необходимо, например, чтобы всего лишь изменить пару связей.

Вообще-то существование двух типов мультиков - это только дань совместимости. Как и элемент GetData. Наверное, на каком-то этапе их следует поместить в раздел "раритет", а позже и удалить из среды.
Значит, логичным является существование ДВУХ (а не одной) разновидностей копирования: с созданием НОВОГО класса (с возможностью его, класса, дальнейшего редактирования), и новый экземпляр ТОГО ЖЕ класса.
Так вот. Все ЭТО в этой версии уже появилось. Обыкновенное копирование - создание нового класса, а ссылка - новый экземпляр класса-оригинала. И именно по указателям идет там работа. Но с небольшими проблемами, как интерфейсного характера, так и на уровне генерации кодов. Про преодолимость интерфейсных проблем рассуждать уверенно не могу (но не вижу принципиальных препятствий исключающих их преодоление), а на уровне генерации кодов - не принципиальные, могу сказать точно.
5) Про осторожность. Если появляется возможность делать рекурсию, то у пользователя есть возможность переполнить память при ЛЮБОЙ осторожности среды. Я выкидывал на форум 20-раз проверенный пример, однако получил ответ - НЕ РАБОТАЕТ !!!. Выясняется - бесконечная рекурсия. Ограничения, что в этом должен участвовать мультик только в динамическом исполнении, и обязательно Ex - не совсем оправданы. Достаточно одного динамического мультика в рекурсивном кольце, вызывающего методы ##add/##delete. Дополнительный интеллект, проверяющий этот факт - это конечно хорошо, но его наличие все-равно не дает гарантий безопасности. Поэтому и его отсутствие не является безусловным препятствием к внедрению фичи рекурсий.
карма: 9

0