Partial classes & forward declarations

Manu turkeyman at gmail.com
Fri Apr 20 05:07:51 PDT 2012


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.

I'm currently rolling with quite a few workarounds for various things, but
I've finally reached an impass.
Here's my problem, and maybe people can suggest some nice workaround to
this one...

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

So apparently forward declarations aren't supported, even though they
appeared to be... then I found this: "The program is looked at as a whole,
and so not only is it not necessary to code forward declarations, it is not
even allowed! "
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.
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.

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

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

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120420/369743f2/attachment-0001.html>


More information about the Digitalmars-d mailing list