So I've been running into cases repeatedly all week where I really need one or the other, or in some cases, both of these so solve some meta problems, relating to rich bindings to a C++ code base.<div><br></div><div>I'm currently rolling with quite a few workarounds for various things, but I've finally reached an impass.</div>
<div>Here's my problem, and maybe people can suggest some nice workaround to this one...</div><div><br></div><div>I have a class, and it contains various method declarations. These methods are to be implemented via mixins which generate stubs binding it to some complex C++ call-through mechanism.</div>
<div>My approach was to allow the user to forward declare the methods, which will tell the compiler all the information about the function call, and then later on, a mixin would scan the class for such methods, and produce the actual function stubs accordingly.</div>
<div>This doesn't work, because the compiler gives me a message that it is an ambiguous call, even though it is actually the exact same function declared twice (once as a forward declaration).</div><div><br>So apparently forward declarations aren't supported, even though they appeared to be... then I found this: <span style="background-color:rgb(246,246,246);font-family:Consolas,monospace;font-size:14px;white-space:pre-wrap">"The program is looked at as a whole, and so not only is it not </span><span style="background-color:rgb(246,246,246);font-family:Consolas,monospace;font-size:14px;white-space:pre-wrap">necessary to code forward declarations, it is not even allowed! "</span></div>
<div>Well, in this case, a forward declaration is necessary, since it effectively provides the compiler with the signature that it can use to generate the function, in a way that looks exactly like a function definition to anyone who is reading the code.</div>
<div>Having failed that, I have a workaround where I name the function with a silly prefix, and make it private... but this makes no sense to someone reading the source for the binding class (they see a weird list of private mangled functions). So I'm not entirely happy with the solution, but it does technically work for the moment.</div>
<div><br></div><div>There is a secondary problem with my workaround though... I can't figure any way to *alias* a function argument, I can only get a typetuple of the arguments. Since I don't have _alias_es of the function args, I have no way to access their 'identifier'(/name), and that leads to a problem where I'm generating the public stub function, and I have nothing to name the args other than a0, a1, a2, etc...</div>
<div>That is complete rubbish, and unusable to an end user by my measure; intellisense is useless if the pop-up argument list says a0,a1,a2. >_<</div><div><br></div><div>There's a third crudeness to my problem, and that is, to generate the bindings, I need to put a mixin in every class. I already have a 'RegisterModule' mixin at the end of the file, which binds all the 'loose'/static methods.</div>
<div>What would be really handy in this case, is to be able to use partial classes as in C# and C++0x to add the extra bits to the previously defined classes all within the one RegisterModule at the end.</div><div>I think partial classes will become considerably more useful too when we have attributes, and some may classes need to have some extra data members added to support their given attributes.</div>
<div><br></div><div>So let's ignore partial classes for the moment, I'm happy enough with the meta spam for the time being. What kinds of tricks can I use to generate the stub functions I want, while preserving the argument names, and sensible declaration/readibility of the module. How else could the functions be declared, short of a string literal, is there any way I can pull out the names of args currently?</div>
<div><br></div><div>I think there's definitely room for a trait to refer to the _instance_ of a function arg in the same way as 'getMember', thus allowing it to be enumerated+supplied to templates as alias parameters.</div>