On Thursday, 11 July 2013 at 07:34:48 UTC, Jacob Carlborg wrote:
On 2013-07-10 20:43, Paulo Pinto wrote:
What sometimes goes missed between the lines is that one of the
decisions to go ARC instead of GC, is because the Objective-C
GC never
worked properly and ARC offers a better fit for the current
state of
Objective-C world.
First of all, GC was an opt-in and very few libraries
supported it.
Wasn't it possible to use the GC with all libraries but not the
other way around?
No, it depended how you compiled the code.
https://developer.apple.com/legacy/library/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcEssentials.html#//apple_ref/doc/uid/TP40002452-SW1
Using -fobjc-gc-only meant your library could only work with GC
enabled applications.
Or another quote from the documentation:
"Not all frameworks and technologies support garbage collection;
for example, iCloud is not supported in applications that use
garbage collection."
Then we have the typical issues with a conservative GC in a C
based
language, which lead to tons of issues if one looks into
developer forums.
The GC only worked for the Objective-C part.
True, but you were forced to do manual hacks like calling
objc_assign_global() for write barriers in global and static
variables.
There is the compiler flag -Wassign-intercept to show where write
barriers are being generated as a help method if everything is
being generated properly.
The Core Foundation needs to be used in a slight different way
when interacting with GC enabled objects.
With ARC all these problems do not exist, because the compiler
does what the developers would be expected to do manually anyway.
This is way there was such a joy when ARC was announced, not
because GC per se is bad.
--
Paulo