Re: Thoughts on Cocoa source code
Re: Thoughts on Cocoa source code
- Subject: Re: Thoughts on Cocoa source code
- From: Jens Alfke via Cocoa-dev <email@hidden>
- Date: Wed, 9 Oct 2019 10:41:32 -0700
> On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev
> <email@hidden> wrote:
>
> Why is Cocoa source code hidden?
So, take this as opinions of someone who worked at Apple, on [among other
things] Mac OS X apps from 2000-2007.
(a) It's part of Apple's crown jewels and seen as a competitive advantage.
(b) It calls all sorts of internal APIs of lower-level components like the
WindowServer, and Apple doesn't want to expose those APIs because they're
undocumented, easily misused, hard to support, subject to change at any moment,
etc.
(c) If developers look at the source code they'll be tempted to make use of
undocumented behaviors, private methods, etc. which makes their apps much more
likely to break in future OS versions. (This already does happen, to an extent,
but with source code it would be much more pervasive, given the dynamic nature
of Obj-C and how easy it is to call internal methods or even patch system
classes.)
(d) Internal source code tends to have comments and identifiers that refer to
internal code names, canceled projects, and other stuff that shouldn't be made
public. Sanitizing this is a pain.
(e) Apple obviously works on lots of features that remain secret for months or
years; these would all have to be kept in private branches, causing all sorts
of merging/rebasing headaches.
(d) It takes quite a lot of effort to maintain a large open source project.
It's not just dumping the source to Github.
> Yeah, the headers are visible, and Apple has
> info online. But sometimes that was not sufficient to understand the actual
> implementation details.
You don't want to use the _implementation_ details! Those can and do change
completely over time — I know NSView has been redesigned/reimplemented at least
twice since 2000 — so making use of them on OS version N could cause your app
to break in version N+1. You want to know the details of the (defined)
_behaviors_. That means better documentation. I agree that Apple could improve
here.
> When debugging, the stack trace inside Cocoa was just a bunch of
> rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes
That's not true; you can use symbolic breakpoints to break on any Objective-C
method, or any C function that has a visible symbol.
> I personally learned C++ while using the PowerPlant library from Metrowerks.
The difference is that PP is code that you link statically into your app. It
doesn't change versions unless you explicitly update it. Cocoa is part of the
OS, and changes one very OS release. Binary compatibility is super important to
Apple, so Cocoa being a "black box" is actually a feature, not a bug.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden