Community
Participate
Working Groups
Assuming we add a preprocessor that can be called by the generators on a given part and can do wholesale analysis and re-organization of the code, one of its logical responsibilities would be to support overloaded functions. This would scan the part to detect overloaded functions, functions with the same name but different signatures in terms of arguments and their types. For each variant, the preprocessor would use some mechanism for allowing the generator to derive the "mangled" function name according to the syntax rules of its target language. This mangling would need access to the MOF Function object, so that it might take into account the function name, number of arguments, and argument types. Another aspect of this would be support for creating a "dispatcher" for overloaded functions. In this sense, the dispatcher is a function that accepts variable args, inspects them, and determines the appropriate function to which it can forward the invocation. Since the function variants are written in terms of EGL types, it makes sense for this dispatcher to always be invoked with boxed args, providing it with the type information it needs. Whether a dispatcher should be generated, and when it should be invoked, will probably need to be left up to the generators to consider, however, it's worth noting that where the generated code must be accessible outside of EGL, the dispatcher will probably be required. However, even if the dispatcher is available, direct invocation of a particular variant will always be more efficient, especially since we usually have enough info. at compile-time to know which variant to invoke.
Setting the target milestone to Future for bugs that won't be addressed in 0.8.2.