Live data from Hacker News

API changes in Snow Leopard

developer.apple.com

1–10 of 19 posts

Re: API changes in Snow Leopard

#3
post #2

I don't know if someone else care, but I find it annoying that the "blocks" proprietary extension to C/C++ is conflicting with C++/CLI syntax for managed pointers.

Isn't the CLI syntax for managed pointers itself a proprietary extension to C/C++?

Re: API changes in Snow Leopard

#4
Fascinating; kill -9 is now the official way to terminate an application.

To support improved shutdown, your application needs to mark itself as “dirty” or “clean,” depending on whether it has unsaved changes and needs to do work before quitting, or can be terminated without further notice. When the system shuts down, clean applications are terminated (via SIGKILL) without further interaction.

Re: API changes in Snow Leopard

#5
post #4

Fascinating; kill -9 is now the official way to terminate an application. To support improved shutdown, your application needs to mark itself as “dirty” or “clean,” depending on whether it has unsaved changes and needs to do work before quitting, or can be terminated without further notice. When the system shuts down, clean applications are terminated (via SIGKILL) without further interaction.

Sounds fine to me. I heard of this idea a few years ago: http://en.wikipedia.org/wiki/Crash-only_software http://lwn.net/Articles/191059/

Re: API changes in Snow Leopard

#6
post #3
post #2

I don't know if someone else care, but I find it annoying that the "blocks" proprietary extension to C/C++ is conflicting with C++/CLI syntax for managed pointers.

Isn't the CLI syntax for managed pointers itself a proprietary extension to C/C++?

They are. And it's pretty unlikely that anyone would code in Objective Managed C++.

Worst thing that could happen would be a slight conflict in the brain of people coding simultaneously in Objective-C and in Managed C++.

Re: API changes in Snow Leopard

#7
The first thing I wanted to see as a Smalltalker was how much they've baked Blocks into the libraries. I know Cocoa has always had very long method names, but some of these names are wild:

- #enumerateObjectsUsingBlock: is #do:

- #objectsPassingTest: or #indexesOfObjectsPassingTest: are #select:

And so on. Here's what I'm looking at:

http://developer.apple.com/mac/library/documentation/Cocoa/R...

Re: API changes in Snow Leopard

#8
post #7

The first thing I wanted to see as a Smalltalker was how much they've baked Blocks into the libraries. I know Cocoa has always had very long method names, but some of these names are wild: - #enumerateObjectsUsingBlock: is #do: - #objectsPassingTest: or #indexesOfObjectsPassingTest: are #select: And so on. Here's what I'm looking at: http://developer.apple.com/mac/library/documentation/Cocoa/R...

The names are silly, and Apple isn't leveraging blocks nearly as much as they could be. The very first thing I did is add an option monad, plus additional collection methods (including the nice and short map and filter) via categories.

My only complaint is that The [[]] messaging syntax gets way too verbose when chaining together sequence comprehensions.

Re: API changes in Snow Leopard

#10
post #9

Mac OS X v10.6 provides support for block objects in C, C++, and Objective-C. Huh? Isn't this a feature of a compiler, not an OS?

I'm not sure why you got down voted to 0 for asking a legitimate question. The block objects are part of Grand Central Dispatch. A programmer tags an isolated unit of work as a block. The OS then takes these blocks and schedules them into execution queues. While the compiler adds support for defining the blocks themselves, OS X 10.6 provides purpose to these blocks. Just like you can have a VM which supports threads on an OS that itself is not multi-threaded, the feature would be pretty useless if only the compiler were updated as it has been for 10.6
Post reply on HN