使用 RTTI 在运行时查找 Delphi 中的所有类助手？
Delphi 2010 中的扩展 RTTI 是否提供了一种在运行时列出定义的 类和记录助手 的方法时间？
据我所知德尔福 不显示提示或警告 当为一个类定义了多个类助手时，类助手检测可能是“质量保证”中的一个有用的例程。
ps 当然，我知道我永远不应该使用没有源代码的第三方组件或库，这将使 grep 类帮助器变得容易。
Does the extended RTTI in Delphi 2010 offer a way to list defined Class and Record Helpers at run time?
As far as I know Delphi does not show a hint or warning when more than one class helper is defined for a class, class helper detection might be a helpful routine in 'quality assurance'.
p.s. of course I know I should never ever use third party components or libraries without source code, which would make it easy to grep class helpers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于类帮助器仅根据范围内“最接近”的帮助器应用于类，因此类根本无法知道帮助器的存在。例如，您可以在您的单元中创建一个班级助手来“帮助”您没有来源的另一个单元中的班级。另一个单元的班级对任何助手一无所知。如果它确实有这些知识，那么就必须重新编译以考虑到这一点......这导致了下一个问题；
考虑一下：您可以在一个公共单元中声明一个类，该类可以被整个应用程序中的许多其他单元使用。在每个单元中，您都可以使用不同的方法和“帮助器”函数为这个公共类声明一个新的帮助器。由于每个单元对也声明自己的助手的其他单元一无所知，因此根据设计，无法以某种方式合并所有助手。现在考虑一下这个公共单元现在跨预编译的包边界。
班里的帮手都是迷人的小异教徒。他们许诺名誉和财富，但往往在你屈服于他们的诡计很久之后，他们就会带来死亡和毁灭。
因此，将它们引入该语言解决了非常具体的问题，即“看似”将功能引入现有框架的能力。只要您遵守“只有一个助手”的规则，并且不偏离这条道路，您可能相对毫发无伤。无论如何，您需要具备贝奥武夫、列奥尼达（斯巴达）和弗罗多·巴金斯那样的肠道毅力才能在这片水域中航行。
鉴于此，在 RAD Studio 团队中，我们不愿意使用可以避免的类助手。当我们使用它们时，在我们开始之前就已经形成了一个适当的方阵……
这里有龙……
Since class helpers only apply to a class based on what helper is "closest" in scope, a class simply cannot know that a helper exists. For example, you can create a class helper in your unit to "help" a class from another unit for which you have no source. The class in the other unit has no clue about any helpers. If it did have this knowledge, then it would have to be recompiled to take this into account... which leads to the next issue;
Consider this: You could have a class declared in one common unit that is used by many other units throughout your application. In each of those units you declare a new helper for this common class with different methods and "helper" functions. Since each unit knows nothing about the other units that also declare their own helper, there is, by design, no way to somehow coalesce all the helpers. Now consider that this common unit now lives across a pre-compiled package boundary.
Class helpers are seductive little heathens. They promise fame and fortune, but too often they rain down death and destruction... long after you've given yourself over to their wiles.
For this reason, their introduction into the language solved very specific problems, namely the ability to "appear" to introduce functionality into an existing framework. As long as you adhere the "one helper only" rule, and do not stray from that path, you may emerge relatively unscathed. Regardless, you will need to have the combined intestinal fortitude of Beowulf, Leonidas (of Sparta), and Frodo Baggins to navigate through these waters.
Given that, here on the RAD Studio team, we are loath to ever use a class helper where it can be avoided. And when we do use them, an appropriate phalanx is formed before we even begin...
There be dragons here...