There's no need for a plan to make the compiler more generic. Anyway, there's a c++ branch in vala created by me, and I had hard time mapping vala to c++ for two reasons: 1) Classes can be used as structs, even Qt does that fir Lists for example. 2) Templates cannot be easily mapped from vala generics to c++ templates, unless you specialize the class. E.g. List<T> to List<string> and call that StringList in vala.
The second point can be reworked to make vala a complete rewrite of c++ somehow, but wasn't my intention in the branch. However the fist point is a real problem. If any of you has a project that maps vala to another language, and you feel the need for a more generic interface of a particular component of vala, I'm willing to help with that. On Sun, Nov 9, 2014 at 6:23 PM, pancake <panc...@youterm.com> wrote: > i think that before accepting patches we need a plan. We have to decide > if we want a subset of Vala, or just to define an interoperability API to > call other languages like C++, Java or ObjC. > > if the plan is to use it just with bindings one can use Valabind, which can > create JNA/JNI or C++ bindings from Vala code (still wip) and then just use > that api from Java or C++ code. > > But I would prefer to be able to call OBJC/C++ code from Vala. The > emscripten > solution to that problem is quite elegant, so maybe we can use it as a way > to create formatted strings at compile time for the generated code. For > example: > > _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
