3 ms·
>...formal specifications that provide details beyond type and signature are relatively rare. I'm not sure what, specifically, they're suggesting the alternati
by renholder 8y ago
>...formal specifications that provide details beyond type and signature are relatively rare.
I'm not sure what, specifically, they're suggesting the alternative is, since their later argument seems to just be to abstract the procedure calls into components and connectors. Most documentation is still just going to list details about the component and/or connector; which doesn't conquer the problem - as referenced above - that the documentation around the specifications will, themselves, still be relatively limited.
Since I'm most familiar with RPC in Windows, let's reference EcDoConnectEx[0] as an example of their suggested model. You're consuming a component (MAPI/RPC), without having to implement the connector (RPC), yourself. It's still a gauntlet of documentation and there's nothing outside of the specification readily available to demonstrate the actual implementation. (At least, I don't recall seeing it in the MAPI Headers.[1])
While agree that procedure calls - in and of themselves - might be too low-level for every-day implementation and consumption, you can have the inverse problem of sandboxing like occurred with .NET (before it was ported to [l]unix via .NET Core). Even then, you're now completely abstracting the low-level from the high-level and, whilst that is entirely easy to program for, it's not - precisely - the case that it's easy for debugging back down to the native layer - where an exception might be thrown.
I've most famously seen this as a native exception (hResult) being translated into an entirely different exception "reason" in managed code (presumably because either every scenario is almost impossible to program for and/or the native layer was changed and the managed layer wasn't aware of the change and/or never caught up to it).
Take this view/perspective with a grain of salt, however, because I haven't programmed in the [l]unix world - outside of some basic Python; so, my anecdotal comment is very much that and should be treated as such. =]
[0] - https://msdn.microsoft.com/en-us/library/ee200938(v=exchg.80).aspx https://msdn.microsoft.com/en-us/library/ee200938(v=exchg.80...
[1] - https://www.microsoft.com/en-us/download/details.aspx?id=12905 https://www.microsoft.com/en-us/download/details.aspx?id=129...