On May 22, 2008, at 6:36 PM, Graham Cox wrote:
On 23 May 2008, at 3:20 am, Andy Lee wrote:
That may be, but that is different from demanding that Apple "lower
the barriers" by changing Cocoa itself to resemble those platforms.
I think many of the additions in Object-C 2.0 and the addition of
garbage collection is *precisely* a case of changing Cocoa to
resemble other platforms (i.e. Java). Personally I don't find any of
the new features all that compelling, though they are no doubt
worthwhile for many. Since veteran Cocoa programmers have managed
fine without any of these for a long time, I can only deduce that
these changes were added by Apple for the express purpose of
lowering the barriers to entry for programmers coming from a Java
or .NET background.
The design goals of properties and GC were to make Cocoa developers
more productive and to give Cocoa developers a better set of tools to
take advantage of modern Macintosh hardware. That the technologies
lower the barriers to entry is certainly true and desirable, but that
was secondary to the goals of the features. Of course, any
improvements to a development environment that *don't* reduce
complexity and *don't* make developer more productive is likely of
questionable value.
Properties
----------
Properties were added quite specifically because we recognized a long
standing setter/getter pattern, along with the additional memory
management and atomicity information, that is pervasive across the Mac
OS X Objective_C APIs.
Properties are specifically designed to allow APIs to declare setter/
getters with more precision within the interface and to reduce the
amount of repetitive code required within the implementation.
Properties were quite specifically designed to continue the generally
fairly explicit delineation between interface and implementation.
Under the 64 bit runtime, properties can also be used to synthesize
the storage associated with a particular property.
Garbage Collection
------------------
Beyond being a great convenience and eliminating one of the most
common bugs in Cocoa programming, GC was added because automating
memory management is one of the best services that can be provided by
the system to aid in the development of code that can take advantage
of multiple cores, of which every macintosh now has.
Under GC, atomicity of operations is far more prevalent than non-GC.
Under non-GC, a setter cannot be implemented that does the correct
retain/release or retain/autorelease behavior without using locks and,
if you want to avoid deadlocks, an exception handler. As well, non-
GC makes passing objects between threads rife with complexity.
GC allows for much simpler multi-threaded development;
@property(atomic) is free for all but structure types.
Finally, the addition of GC enables the Mac OS X engineering team to
further optimize memory management in ways not necessarily possible in
the prior scheme. As the collector improves over time -- and it
will improve! -- GC'd applications will automatically gain the
benefits of said improvements.
b.bum
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
