4 ms·
What part of that example requires RTTI? Clearly the type of `factory` (and thus the type of values it produces, even if they vary with input values) is known a
by colanderman 9y ago
What part of that example requires RTTI? Clearly the type of `factory` (and thus the type of values it produces, even if they vary with input values) is known at compile time, thanks to the cast. And confirming that the dynamically loaded code adheres to that type is a loader problem (which can be solved with metadata), not a language/runtime problem (which would require RTTI and the overhead of checking it).
The point of a static type system, either HM or a DT system, is to ensure that the types are either known at compile time, or derivable from some other runtime value (e.g. input to a function). This is for two reasons: safety, and the ability to elide RTTI. (Note that a type system forbids you from doing anything with a value with a dependent type until it finds its way into a conditional branch which simplifies its type to a non-dependent one.)
- jcelerier 9y ago> thanks to the cast. well, exactly: languages are able to do without the cast at all, just extracting type information from the runtime, which is much safer.
- colanderman 9y agoYou wrote the example, not me. I'm confused what your argument is. Are you saying that dynamic loaders should check the type of dynamically loaded code against the type expected by the code loading it? I agree that's a good idea, but it doesn't require language support for general RTTI, just a type-aware shared-object format and dynamic loader. (Heck, C++ symbol names already incorporate function argument type signatures, so this isn't a huge stretch.) Are you saying that a runtime shouldn't need to trust that dynamically-loaded code actually implements the interface it claims to? If so, that's an incredibly specific requirement that's really better served by sandboxing or an RPC-like interface (especially in C/C++).