Поскольку хелперы класса применяются только к классу на основе того, какой хелпер является «ближайшим» по области действия, класс просто не может знать, что хелпер существует. Например, вы можете создать помощника класса в своем подразделении, чтобы «помочь» классу из другого подразделения, для которого у вас нет источника. Класс в другом блоке понятия не имеет о каких-либо помощниках. Если бы у него было это знание, то его пришлось бы перекомпилировать, чтобы учесть это... что приводит к следующей проблеме;
Подумайте об этом: вы можете объявить класс в одном общем модуле, который будет использоваться многими другими модулями в вашем приложении. В каждом из этих модулей вы объявляете новый помощник для этого общего класса с разными методами и «вспомогательными» функциями. Поскольку каждый юнит ничего не знает о других юнитах, которые также объявляют свой собственный хелпер, по замыслу нет способа каким-то образом объединить всех хелперов. Теперь учтите, что эта общая единица теперь находится за границей предварительно скомпилированного пакета.
Классные помощники — соблазнительные маленькие язычники. Они обещают славу и богатство, но слишком часто обрушивают на вас дождь смерти и разрушения... еще долго после того, как вы поддались их уловкам.
По этой причине их внедрение в язык решало вполне специфические задачи, а именно возможность «явиться» для внедрения функционала в существующий фреймворк. Пока вы придерживаетесь правила «только один помощник» и не отклоняетесь от этого пути, вы можете выйти относительно невредимым. Несмотря на это, вам понадобится объединенная внутренняя стойкость Беовульфа, Леонидаса (Спарты) и Фродо Бэггинса, чтобы перемещаться по этим водам.
Учитывая, что здесь, в команде RAD Studio, мы не хотим когда-либо использовать помощника класса там, где его можно избежать. И когда мы их используем, соответствующая фаланга формируется еще до того, как мы начинаем...
Здесь драконы...
person
Allen Bauer
schedule
10.02.2010
