OCTAGRAM

Let's not talk about solution "for Pascal". Solution for sane language it should be called, and Pascal is only guilty of being sane. By the way, circular reference is not the only reason. Forward declaration can be left unsatisfied just because. IIRC EF is missing information even for #include idl For Delphi one may need Int64 Result hack to pass around 8-byte records which are in eax:edx according to SOM vision of stdcall, but Delphi's vision of stdcall is to always pass record Result by reference....

I was starting with C-style bindings. They are in my repository history somewhere or maybe remaining in head. Problems were from forward declarations. Pascal/Ada permit forward declarations, but all loops have to be closed within one source. That makes Pascal/Ada very nice languages with modular structure, but hard to map WinRT, SOM and many stuff from outside world because those alien software engineers do not follow these rules. An IDL file can have forward declaration of some interface and never...

Hi, Yuri. I can see you're digging hard lately. As I recall, there was a problem with Emitter Framework not enough for emitting single source file, and Interface Repository Framework was enough, but precious information was lost. And my probable solution was to make something like IR emitter, but richer, and then it should be possible to produce relatively good bindings from rich IR. Attempt to bind to Pascal was pathetic without rich IR.

Microsoft were never supposed to work on this. Windows as we know it, is produced by division of labour. Intel defines binary object formats: first OMF, then PE. Microsoft writes kernel. Borland provides development tools, and now it's Embarcadero who is in charge for Windows development. Sometimes Microsoft managed to accelerate progress by kicking Borland. Microsoft made UTF-16 the only encoding in COM, and reference counting as the main memory management policy. Without that kick Borland was not...

AFAIK DCE had no reference counting. So Microsoft could possibly also maintain compatibility with something, this time DCE, and build trash that nobody likes after all, and nobody cares about DCE compatibility after all. I think, another more serious reason for ugly SOM without RC was C++ D2SOM. I was wondering why IBM didn't provide rich frameworks based on SOM. I install VisualAge for C++ 3.5.9 on Windows. D2SOM is not abandoned yet in this version (it will happen in 3.6). SOM is the way to go....

Simplicity is: Forgetting SOMEF ever existed Extending SOM.IR to contain explicit types, comments and passthru Wielding SOM compiler with extended IR emitter and pretending it was always united like this Rewriting other emitters to work with extended IR

I forgot one more thing. Why does it fail with SOMEF as is. Emitter receives just a single class definition. Even if you force SC to see all the forward definitions, emitter won't receive them. Won't be able to perform topological sort and other nontrivial actions like copy-pasting parent class methods into current bindings.

Indeed, they fail. But what do you propose instead? Imagine you have an empty SOM.IR database. It's the very first invocation of ir emitter, and some forward definition remains unsatisfied. I can gather a self-sufficient database and produce a good looking bindings. I mostly agree, but there are still some options to choose from. I can reject incomplete databases. I can map to SOMObject. I can map to SOMObject descendant without any additional methods, but that will make it incompatible with random...