> On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev > <cocoa-dev@lists.apple.com> 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 (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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
