Some thoughts about OSX integration in XE2
By A.Bouchez on 2011, Sunday September 25, 19:54 - Pascal Programing - Permalink
You know all that one of the most exciting features of Delphi XE2 is the
MaxOSX Cross-Platform feature.
You've got the UI part,
that is FireMonkey, but underneath, you did have some RTL modifications in
order to let our Windows-centric solutions be OSX ready.
The first main step was to make our code speak with the "Objective-C" way of coding.
Objective-C is the primary language used for Apple's Cocoa API, and it was originally the main language on NeXT's NeXTSTEP OS. It's some object-oriented C variant, but something other than C++ or Java. In fact, Objective-C sounds more like a SmallTalk variance of C than another C++/Java/C# flavor. For instance, the Objective-C model of object-oriented programming is based on message passing to object instances: this is just another way of doing it. It has some advantages, and disadvantages (I don't want to troll here) - but it is definitively nice. And the memory model is just something else, more close to our reference-counting way (as in Delphi interface implementation) than a garbage collector.
About Objective-C, it sounds like if Embarcadero did make its own Delphi-based wrapper around the OOP layout of this technology. In short, messages were encapsulated inside methods, and exposed as interfaces. Embarcadero RTL team used the new RTTI and generics language features to expose the Objective-C API into standard Delphi interfaces.
FPC did extend the compiler so that Objective-C style of coding appeared in the code: this is the so-called "Objective Pascal" mode, which handle both its message and memory model as native features, at the compiler level.
I don't have any preference. Both have pros and cons. The FPC solution sounds lighter and automated (the OSX APIs are created using an automated process). The EMB solution sounds more "pascalish", since the language was not modified, but some wrappers were designed over the OSX APIs.
What is nice in both case is that we are not stick into the flat Carbon API, which is 32 bit only. Calling directly the Cocoa APIs will release the full power of Mac OSX, and allow to write 64 bit applications (already for FPC, in the future for Delphi).
The new "unit scope names" introduced in Delphi XE2 for handling several
platforms (Windows/Posix or VCL/FireMonkey) do make sense to me. By the way, it
seems definitively better than the previous LibC huge unit, as used for Kylix.
And perhaps more rigid than the FPC library.
In practice, I had to modify our framework source code for all VCL-refering
unit names. But nothing difficult - just one step
preparing for FireMonkey.
In all cases, this is a quite interesting step into cross-platform.
Nice talking about it on our forum, if you wish.