Re: Thoughts on Cocoa source code
Re: Thoughts on Cocoa source code
- Subject: Re: Thoughts on Cocoa source code
- From: Aandi Inston via Cocoa-dev <email@hidden>
- Date: Wed, 9 Oct 2019 19:39:50 +0100
" . Cocoa is part of the OS, and changes one very OS release. "
This reminds me of a question which pops up for me every few years in
development. I can't call to mind the last
specific details, but it will happen again.
Let's create an imaginary problem:
* Apple add a new class behaviour to Cocoa in macOS 10.15. We'll suppose
they add [NSApplication doUsefulThing]
* But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get
a compile-time warning. Still, I'd
really like to do the useful thing anyway, and without changing the SDK for
whatever reason.
* I add a check for actual OS version, so I am very sure not try to call
[NSApplication doUsefulThing]
unless the OS is 10.15 or later.
* But what happens if it runs in 10.15? Does it actually do the useful
thing?
Are the Cocoa methods entirely dynamically loaded/provided by the live OS?
Or does anything get statically linked,
flagged, is the binary's SDK version checked or is there anything else that
will prevent this call doing the
useful thing?
Thanks in advance!
On Wed, 9 Oct 2019 at 18:42, Jens Alfke via Cocoa-dev <
email@hidden> wrote:
>
>
> > 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
>
_______________________________________________
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