In the absolute to do something based on com & IDL, it would be easy to come up with something like this :
Class myModule : IDL_INTERFACE
{
Int method1 (int a, string b)
{
mem_zone_ref params={ptr_null};
create_obj (¶ms,"params",type_json_object);
set_key_int (¶ms,"a",a);
set_key_str (¶ms,"b",b);
module_call ("myModule", "method1",¶ms);
deRef (¶ms);
}
}
IDL_interface *myInterface=new MyModule ();
myInterface->method1 (18, "toto" );
Or the opposite
Class jsonRPCHost
{
IDL_interface myInterface=MyModule ();
JsonResult method1(string jsonParams)
{
mem_zone_ref params={ptr_null};
Int a;
String b;
tree_from_json (jsonParams, ¶ms);
get_key_int (¶ms,"a",&a);
get_key_str (¶ms,"b",&b);
myInterface->method1 (a,b);
deRef (¶ms);
}
}
jsonRPCHost rpc;
rpc.method1 ("{a:18,b:\"toto\"}");
Or can do same for passing parameters as json array instead of named values.
rpc.method1 ("[18,\"toto\"]");
To have binding between com interface , json/rpc interface, and the binary modules.
The code to extract the parameters need to be changed, rpc support the two modes, with my code it detect if the json is an array and the module need to adapt the params parsing if it use array or named values. By default it use an array for the moment, but using named value would allow to pass directly jsonified js objects to the rpc on the client side, here the js api build the array out of the js object for the rpc.
generic module call in C
tree_from_json ("{a:18,b:\"toto\"}", ¶ms);
module_call ("myModule", "method1" ,¶ms);
the name of the method can be extracted from the full json rpc request.
with "mod.method" synthax in the rpc request, the runtime function executing the call to the module method could make the call automatically with generic code for any rpc request .
For the moment it use http url path to determine the module name, and the config file bind the http path to the module interface, either it's used as a cgi and extract the parameters from http query string, or with the rpc interface, both can be used. The block explorer use the cgi api with parameters from the http query string, the wallet use the rpc api.
In any case, the module call can be made to local module, or to remote module via http/rpc/request, the C synthaxe just remove the boilerplate of c++ object definition, and in the end the c++ interfaces just translate parameters to/from json to c++ compiler specific data, to potentially retranform it back to json to make rpc call.
The c++ interface definition just add boilerplate, break binary compatibility, and is not even very useful from js app point of view. Can make développement of module easier using c++ synthax, but that's about it. And I dont think can expect opengl C++ app too soon anyway. And other than for doing opengl app,the js api can do it, and it can still somehow handle opengl even if rpc call are slow.
Maybe for programing pure server side modules without UI, it could be useful to have c++ layer to make code typing faster, but it raise certain question with error checking & c++ operators. Without using exception I dont see how to check operators error, and without operators it would end barely less fugly in c++. For the interfacing glue code can be made to interface c++/com with json for js rpc & other modules. But doing an interface to handle inter object operators is not easy. And then the module execution cant be distributed because of the operators instead of using the C synthax.
With a bit more work it can embedded into IE, and script in vb,c#, and js with ie ( without rpc interface, with com runtime ), but that work only for Microsoft stuff.
The equivalent of this is XPCOM which is supposed to be more portable, ff & chrome & safari can use those, even if chrome is dropping it, and will develop something else, safari have their own native plugin format, but it support the XPCOM thing.
But even under linux, it's not widely used to develop application, it's mostly used by browser, to define the DOM objects, and the plugin, but outside of flash the other plugin are marginal.
So in the end this can be third way to develop more a COM/XPCOM like approach in c++. Im not sure how far IDL can go with design pattern, I think you can at least define method who deal with other IDL interface, there might be way to define complex type but not sure, most likely conversion from json object to c++ method parameters need to be done manually with json object members passed manually with the good order to the IDL interface method.
To have something similar to c++ operators with COM , you would have
StringInterface *A;
IntegerInterface *B;
Int value;
A=rpc->getStringInterface ("1234");
B=A; // automatic operator overload defined in the interface, return the interface to an instance of B
value=B->getValue (); // rpc call
B->deRef (); // rpc call
If A and B implementation are hosted remotely , it mean the host need to keep an instance of B as long as the client needs it, and it make three rpc request to have the equivalent of operators.
And you could get to
Value=A->B-->member [xx]->method1 ().result.value;
With rpc call each time, but it's hard to have good error handling, or asynchronous requests with a synthax like this in c++. If one call return invalid object interface, it mean most likely crash. And it's not always possible to know if the function will succeed with remote calls.
So in the end to have something safe , it will always be fugly in a way or another.
In C you can get same operation in one call with explicit typing
Json_to_tree ("\"toto\"",¶ms);
module_call("A","getValueToInt",¶ms,&value);
// params contain eventually data used by the operator
// or the operand like B represented as json object if the operator use the value of B
// value is the return value represented as json object or in binary form if the return type is explicit in the module call declaration.
But it need to make each call step by step with fugly synthax.
There is a single rpc request , and no boilerplate for the api call itself, but boilerplate in the code to manipulate the binary json object from C. ( but again the code is very safe, and hard to make crash, there will always be a meaning full answer to interface method call).
Other than IDL I dont see other interface definition that has really practical advantage.
But there is no really convenient easy way to force javascript to use a particular format out of an interface definition, or to have anyway to check the object that is passed to the rpc method call from js is the format used to define the interface in c++, or to check from js the result is the type it expect.
My main concern is not optimisation but a language to program blockchain node must have good support for all these:
network api, asynchronous io is a big plus, upnp is big plus
http protocol, json, data format, compression, url & query string parsing, utf8 etc
object serialization and hashing.
Elliptic crypto.
Database system.
GC / ref counting is must.
Simd vectorial math and opengl are a big plus.
Good threading support is big plus.
No need for virtual machine or interpreter is big plus.
Easily work with html templating or integrated ui small plus, templating can be done in browser from json, or html can be made externally.
With all this in mind there is not many language who fit the bill, and even without premature optimization once you are stuck with a language framework, there is not always good way to optimize much more, or work around certain bugs or deficiency in one area or the other.
Other than C and C++ I dont see what other language can fit the bill, not even getting in resources uses, memory, performance, and access to local system/hardware resources, binary compatibility, etc
^^^
and it support aligned simd 128 bits operation too 
