API changes in Snow Leopard(developer.apple.com)
developer.apple.com
API changes in Snow Leopard
http://developer.apple.com/mac/library/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_6.html#//apple_ref/doc/uid/TP40008898-SW1
4 comments
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/
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?
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
It also needs the instantiation support at the VM/runtime level, which is separate from the services the OS itself provides.
So blocks need to be supported at the compiler level, in the Objective-C runtime and in OS-wide processes (which would be Grand Central itself).
So blocks need to be supported at the compiler level, in the Objective-C runtime and in OS-wide processes (which would be Grand Central itself).
This is one reason why I like the old NeXT term "system software" in favor of "OS". (The former is all inclusive.)
Blocks are a language feature, and do need compiler support. The version of the compiler that you need to use them in GCD comes with v10.6 system software.
Blocks are a language feature, and do need compiler support. The version of the compiler that you need to use them in GCD comes with v10.6 system software.
It involves compiler and runtime changes, although they have been backported to the iPhone and 10.5:
http://code.google.com/p/plblocks/
http://code.google.com/p/plblocks/
OS X includes its own compilers.
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...
- #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 make perfect sense within the context of the language. Just because you add a new feature to a language doesn't mean you should arbitrarily adopt the naming conventions of its implementation in another language.
It's nice they retrofit blocks into the lib though, I didn't think they were going to add them beyond GCD.
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.
My only complaint is that The [[]] messaging syntax gets way too verbose when chaining together sequence comprehensions.
I call it "ctrl+space semantically-aware word completion" and "self-documenting function names."
Nothing unusual in multi-year multi-programmer software.
As much as I like succinct function names, in my experience they don't work when there's more than one hacker involved. A strategy I have followed is to make long names for the top-level, interface-like functions, and succinct ones for all the internals; i.e. put the verbosity where others need to look up code to use it as a library, where "library" is understood as an individual/indepenent component of a larger software project.
Nothing unusual in multi-year multi-programmer software.
As much as I like succinct function names, in my experience they don't work when there's more than one hacker involved. A strategy I have followed is to make long names for the top-level, interface-like functions, and succinct ones for all the internals; i.e. put the verbosity where others need to look up code to use it as a library, where "library" is understood as an individual/indepenent component of a larger software project.
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++.
Worst thing that could happen would be a slight conflict in the brain of people coding simultaneously in Objective-C and in Managed C++.
C++/CLI was originally developed by Microsoft and then standardized by ECMA.
OpenCL was originally developed by Apple and then formalized by the Khronos Working Group.
So, it kind of depends on your definition of proprietary.
OpenCL was originally developed by Apple and then formalized by the Khronos Working Group.
So, it kind of depends on your definition of proprietary.
Is it proprietary? I thought it was open-sourced, and submitted to the standards body?
("citation needed", I haven't checked this)
("citation needed", I haven't checked this)
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.