[capi-sig]Re: Learning from JNI [was: Opaque handle API]
[Adding back the list - I assume dropping it was an accidenty]
On 04Mar2019 1234, Neil Schemenauer wrote:
On 2019-03-03, Steve Dower wrote:
In my opinion, you can dislike many of the Windows-specific "enhancements" around COM (like DCOM, etc., and I do dislike them), but the core concepts are very well proven, including being used from JavaScript and .NET (fully GC languages). Perhaps moreso than JNI?
Thanks Steve. You are correct, we should learn from COM too. Do you have any suggested references? I poked around some in the CoreCLR repo on github. E.g. this was pretty interesting:
https://github.com/dotnet/coreclr/blob/master/Documentation/botr/exceptions.mdAre there documents in the open source "dotnet" that would be relevant to the COM design implementation? I think a challenge with COM is that it is more comprehensive and therefore more complicated. So, for outsiders, it could be more difficult to understand how it works.
I'd suggest looking at the design notes here instead:
https://github.com/Microsoft/xlangThis is the cross-platform implementation of the "core" of COM (basically, the cross-language ABI part without necessarily including the magic cross-process/machine and proxy/marshalling support that is considered part of COM on Windows).
There is also a tool in that repo for generating Python C extensions to project objects defined in xlang/COM into Python. Since most of the new Windows API (from Win8 onwards) is defined like this, that's their first examples, but it's not at all tied to Windows.
Cheers, Steve
On 05Mar2019 0926, Steve Dower wrote:
[Adding back the list - I assume dropping it was an accidenty]
On 04Mar2019 1234, Neil Schemenauer wrote:
On 2019-03-03, Steve Dower wrote:
In my opinion, you can dislike many of the Windows-specific "enhancements" around COM (like DCOM, etc., and I do dislike them), but the core concepts are very well proven, including being used from JavaScript and .NET (fully GC languages). Perhaps moreso than JNI?
Thanks Steve. You are correct, we should learn from COM too. Do you have any suggested references? I poked around some in the CoreCLR repo on github. E.g. this was pretty interesting:
https://github.com/dotnet/coreclr/blob/master/Documentation/botr/exceptions....
Are there documents in the open source "dotnet" that would be relevant to the COM design implementation? I think a challenge with COM is that it is more comprehensive and therefore more complicated. So, for outsiders, it could be more difficult to understand how it works.
I'd suggest looking at the design notes here instead:
https://github.com/Microsoft/xlang
This is the cross-platform implementation of the "core" of COM (basically, the cross-language ABI part without necessarily including the magic cross-process/machine and proxy/marshalling support that is considered part of COM on Windows).
FWIW, my favourite part of this design for our purposes is the QueryInterface function. So our "handle" supports a few core operations, one of which is "give me this very specific interface, or else fail", which could let callers do things like (warning: very pseudo-pseudocode ahead):
if (obj->QueryInterface(PYTHON_DICT_STR_TO_OBJECT, &dictStrToObject)) { return dictStrToObject.getItem("my_key"); } else if (obj->QueryInterface(PYTHON_DICT, &dictObjectToObject)) { return dictObjectToObject.getItem(StrFromChar("my_key")); } else { return getitem->callMethod("__getitem__", NewTuple(1, StrFromChar("my_key")), nullptr); }
That way the "base" API is always going to match what Python does, but we can provide optimised interfaces with more direct access to the underlying object. And since these are defined from the start as optional, callers can't assume they'll succeed.
Behind the "PYTHON_DICT*" constants are UUIDs, which means we can also support versioning quite transparently and in an opt-in basis if we come up with a faster way to do things.
(The other core operations in COM and AddRef and Release, which map directly to Py_INCREF and Py_DECREF but are function calls through a v-table, rather than macros directly into memory. For GC'd languages, this can be a pin count rather than a strict reference count - that's basically how .NET and JavaScript handle this today.)
Cheers, Steve
participants (1)
-
Steve Dower