在运行时使用RTTI查找Delphi中的所有类助手？ [英] Find all Class Helpers in Delphi at runtime using RTTI?

问题描述

Delphi 2010中的扩展RTTI是否提供了一种列出定义的类和记录助手在运行时？

Does the extended RTTI in Delphi 2010 offer a way to list defined Class and Record Helpers at run time?

据我所知Delphi 不显示提示或警告，当定义了多个类助手时一个类，类帮助检测可能是质量保证中的一个有用的例程。

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'.

ps当然，我知道我永远不应该使用没有源代码的第三方组件或库，这样可以很容易地对类助手进行grep。

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.

推荐答案

由于类助手仅适用于基于范围中最近的帮助器的类，所以类根本无法知道帮助器存在。例如，您可以在单元中创建一个类帮助器，以帮助您从没有源的另一个单元中的类。另一个单位的班级对任何帮手都没有线索。如果它有这样的知识，那么它将不得不重新编译，以考虑到这导致下一个问题;

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.

因此，他们介绍语言解决了非常具体的问题，即出现将功能引入现有框架的能力。只要你坚持只有一个帮手的规则，不要偏离那条路，你可能会相对毫发无损地出现。无论如何，您将需要将Beowulf，斯洛伐克的Leonidas和Frodo Baggins组合起来，在这些水域进行导航。

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.

鉴于此， RAD Studio团队，我们不想使用类帮助器，可以避免。当我们使用它们时，在我们开始之前就形成了一个合适的方阵。

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...

这里有龙...

这篇关于在运行时使用RTTI查找Delphi中的所有类助手？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！