"Ross Paterson"
But I don't understand how the API versioning works, when the version is selected by the interpreter rather than the DLL.
Sigbjorn's description of how it works describes the status quo but I think we can/should look at changing it. It is my intention that we should stop supporting code generated using 'greencard --target=hugs' since the --target=ffi code does at least as much. We should have a strategy to detect problems caused by dropping support but no more. So, looking at code generated using 'hugs +G', etc. what we're worried about is people using code generated by old versions of Hugs where the binary layout of the virtual table may be different. The simplest way to detect problems would be to have a simple consistency check. For example the 'API number' could be the release date for that Hugs version (e.g. 03022003). This should be inserted in the generated C code. Easy to maintain, works ok with binary packaging systems, will require some recompilation sometimes. We could get fancier (as Hugs was until a month or so ago) and maintain the last few major versions of the binary API. The only difference here is thet the interpreter will accept one of several different API versions. More hassle to maintain for us, a bit easier for people upgrading Hugs or maintaining binary packages. My current feeling is that it's a good idea to check a version number but that supporting more than one version of the binary API isn't necessary. -- Alastair ps There are fancier variants on this plan where the generated code finds functions in the vtable by doing lookups like: cache.getInt8 = hugs->find_function(HUGS_GET_INT8); cache.getInt16 = hugs->find_function(HUGS_GET_INT16); cache.getInt32 = hugs->find_function(HUGS_GET_INT32); The lookup key would be like a COM UID - any change to the semantics of a function requires that the UID be changed. It'd be more tedious changing the code to be like this but easier to maintain in the long run.