Start with synchronous function calls instead of JSON. Microsoft knows how to do that - they invented COM and OLE. Function calls enable whatever data sharing is necessary to maintain a coherent view. Imagine trying to do OLE with JSON - just wouldn't work. (Does OLE still exist?)
Actually, COM is inspired by DCE/RPC and the initial versions had some similarities.
Parallel to that, IBM had SOM on OS/2, which was even better allowing for metaclasses and proper class inheritance, it was the key mechanism between Smalltalk and C++ on OS/2, where Smalltalk enjoyed a role similar to .NET on Windows nowadays.
OLE naturally still exists when using Office natively on Windows, other vendors seem to have forgotten about it.
COM's role on Windows has grown since Vista, and the Windows team redid many of the Longhorn ideas originally implemented in .NET into COM/C++, with WinRT being an evolution of COM.
I've never heard of anyone calling SOM 'better' at anything this century. I came across it when it was the foundation for OpenDoc at Apple, your comment brought back many bad memories
Classes and metaclasses sound like architecture astronomy here. COM is fundamentally just a standard ABI and a way to look up DLL paths in the registry. There are more layers on top of that, but that's the basics and all you need for a plugin architecture.
Interesting to complain about one and then ignore exactly the same boilerplate for the other.
Leaving aside the fact that Microsoft's tooling for COM has already had multiple reboots between VB OCX, MFC, .NET Framework RCW/CCW, .NET ComWrappers, ATL, WRL, WIL, WinRT, each one with its share of astronomy.
Everything uses the bare bones vtbl. That's how there can be so many things, they're all using the bare bones vtbl. Obviously there's application specific stuff as well because a bare bones vtbl is not useful by itself but that's like saying if TCP is so good why is there HTTP?
octoberfranklin · · focus · HN ↗
LSP is an example of utterly horrid technical design.
Stop letting Microsoft design protocols and APIs. They are so. bad. at. it.
duttish · · focus · HN ↗
mitxela · · focus · HN ↗
pjmlp · · focus · HN ↗
Parallel to that, IBM had SOM on OS/2, which was even better allowing for metaclasses and proper class inheritance, it was the key mechanism between Smalltalk and C++ on OS/2, where Smalltalk enjoyed a role similar to .NET on Windows nowadays.
OLE naturally still exists when using Office natively on Windows, other vendors seem to have forgotten about it.
COM's role on Windows has grown since Vista, and the Windows team redid many of the Longhorn ideas originally implemented in .NET into COM/C++, with WinRT being an evolution of COM.
mamp · · focus · HN ↗
pjmlp · · focus · HN ↗
mitxela · · focus · HN ↗
pjmlp · · focus · HN ↗
Interesting to complain about one and then ignore exactly the same boilerplate for the other.
Leaving aside the fact that Microsoft's tooling for COM has already had multiple reboots between VB OCX, MFC, .NET Framework RCW/CCW, .NET ComWrappers, ATL, WRL, WIL, WinRT, each one with its share of astronomy.
No one uses the bare bones vtbl and nothing else.
mitxela · · focus · HN ↗
Everything uses the bare bones vtbl. That's how there can be so many things, they're all using the bare bones vtbl. Obviously there's application specific stuff as well because a bare bones vtbl is not useful by itself but that's like saying if TCP is so good why is there HTTP?
pjmlp · · focus · HN ↗
The point being that beyond the plain vtbl, SOM was much better designed than COM, in the sense of overall architecture for application development.