4 ms·

This is mostly just a random tidbit but one of the fascinating things to me about Swift <-> ObjC interop is that it's not just that Swift was modified for ObjC,

This is mostly just a random tidbit but one of the fascinating things to me about Swift <-> ObjC interop is that it's not just that Swift was modified for ObjC, but ObjC was modified for Swift as well. In general it works pretty well and I wonder how much of that is because Apple can modify ObjC whenever it wants.

pjmlp 6y ago
.NET <-> C++/COM also went through a similar process.
- snuxoll 6y ago
  .Net is a much simpler integration, all of the support is in the CLR because COM defines a limited ABI that can be called from any language that can walk a few pointers in a C++ vtable given an interface definition. One can even completely ignore the RCW/CCW support in .Net entirely and just hack together some struct types that match the vtable layout.
  - pjmlp 6y ago
    Old style COM yes, UWP supports much more, value types, enumerations, generics, partial support for implementation inheritance (in context of XAML). Also you ignored that .NET was made to fully support C++ via Managed C++, replaced with C++/CLI on version 2.0.
    - snuxoll 6y ago
      The WinRT ABI does implement some new features, yes - but they’re all still implementable with nothing more than standard C# code with no special support from WinRT itself (in fact, the WinRT ABI integration is being stripped out of the runtime and cswinrt is the way forward). C++/CLI ultimately still uses the same features the runtime uses for p/invoke calls, though it uses slightly different IL to transition to native code since it doesn’t have to worry about an external ABI within a mixed mode assembly. Sure, there’s a whole compiler that supports this weird mixed mode world from a language perspective - but it’s really boring at runtime.
      - pjmlp 6y ago
        All of that doesn't change the fact that there is tooling in place, and language features (e.g. dynamic for COM, upcoming C#9 improved native FFI) to ease interoperability between managed and some level of C++. Something that no UNIX does, and we only find similar ideas in Swift/Objective-C++, IBM language environments, and the old OS/2 SOM (Smalltalk/C++). While everyone else just writes glue code with C like interfaces, as if the world has hardly changed from UNIX V6.
        snuxoll 6y ago
        Purists may hate it, but as a toy project I’ve been working on making a stripped-down version of the WinRT concepts that runs on Linux (well, anything with a c++17 compiler and a dlopen function provided by a linker). The guy behind cppwinrt started work on the Xlang project in a similar vein, but it’s currently not being worked on so I figured I’d give it a shot. I agree that C as the lowest common denominator sucks.
        pjmlp 6y ago
        Good luck with it. Project Reunion seems to have rebooted everything, which is most likely the reason for it to have stalled.

pjmlp 6y ago

.NET <-> C++/COM also went through a similar process.

snuxoll 6y ago
.Net is a much simpler integration, all of the support is in the CLR because COM defines a limited ABI that can be called from any language that can walk a few pointers in a C++ vtable given an interface definition. One can even completely ignore the RCW/CCW support in .Net entirely and just hack together some struct types that match the vtable layout.
- pjmlp 6y ago
  Old style COM yes, UWP supports much more, value types, enumerations, generics, partial support for implementation inheritance (in context of XAML). Also you ignored that .NET was made to fully support C++ via Managed C++, replaced with C++/CLI on version 2.0.
  - snuxoll 6y ago
    The WinRT ABI does implement some new features, yes - but they’re all still implementable with nothing more than standard C# code with no special support from WinRT itself (in fact, the WinRT ABI integration is being stripped out of the runtime and cswinrt is the way forward). C++/CLI ultimately still uses the same features the runtime uses for p/invoke calls, though it uses slightly different IL to transition to native code since it doesn’t have to worry about an external ABI within a mixed mode assembly. Sure, there’s a whole compiler that supports this weird mixed mode world from a language perspective - but it’s really boring at runtime.
    - pjmlp 6y ago
      All of that doesn't change the fact that there is tooling in place, and language features (e.g. dynamic for COM, upcoming C#9 improved native FFI) to ease interoperability between managed and some level of C++. Something that no UNIX does, and we only find similar ideas in Swift/Objective-C++, IBM language environments, and the old OS/2 SOM (Smalltalk/C++). While everyone else just writes glue code with C like interfaces, as if the world has hardly changed from UNIX V6.
      - snuxoll 6y ago
        Purists may hate it, but as a toy project I’ve been working on making a stripped-down version of the WinRT concepts that runs on Linux (well, anything with a c++17 compiler and a dlopen function provided by a linker). The guy behind cppwinrt started work on the Xlang project in a similar vein, but it’s currently not being worked on so I figured I’d give it a shot. I agree that C as the lowest common denominator sucks.
        pjmlp 6y ago
        Good luck with it. Project Reunion seems to have rebooted everything, which is most likely the reason for it to have stalled.