|This is the talk page for discussing improvements to the Cocoa (API) article.|
|WikiProject Apple Inc.||(Rated C-class, Mid-importance)|
|WikiProject Computing / Software|
- 1 Non-subpage name
- 2 Changes from Cocoa programming talk page
- 3 Bias?
- 4 Garbage collection deletion
- 5 Reverted edits
- 6 Becoming excessively detailed?
- 7 Name change?
- 8 Copyediting
- 9 Acquisition date of NeXT
- 10 Wikibook
- 11 KVC
- 12 Event loop
- 13 End-user info
- 14 Fair use rationale for Image:Cocoa dev screenshot.png
- 15 Pronunciation
- 16 Cocoa Touch
- 17 Typos in Rich objects section
- 18 Cocoa Vs. Carbon
- 19 AppleScript Studio and Snow Leopard
- 20 Programing language?
- 21 Cocoa apps aren't necessarily better
Can anyone think of a good non-subpage name for this page? -- Tarquin
- "Cocoa (software)" it is. Thankyou Ed for being bold! -- Tarquin
Changes from Cocoa programming talk page
The following comes from Talk:Cocoa programming:
Suggestions for Future Changes:
- There's a lot more that can be said about Cocoa.
- Some of the frameworks should be mentioned.
- We should check out some of the info at the Cocoa Dev Wiki.
I'm new here, but doesn't this page seem disturbingly partisan? The talk about the lack of garbage collection and the (from my point of view) senseless rambling about DOM smacks of advocacy where none is called for.
How would it be if we stuck to facts? Cocoa is based on Objective C. Objective C has no global automatic garbage collection, but rather uses local garbage collection through autorelease pools instead. How about that? -- Jharrell 01:35 8 Jul 2003 (UTC)
However, it seems Apple next release of ObjectiveC will have garbage collection (and I suppose it will be employed in Cocoa too). If you look at the sources of the gnu compiler, you can see it. McOsten 24 Aug 2006
Garbage collection deletion
I just deleted
"In this way, autoreleased objects behave precisely like Java objects. They are automatically garbage-collected when they move out of scope. " from the page. The description given does NOT describe anything like Java's true GC nature. (It seems that when a varable goes out of scope, it can be GC'd, unlike java where it is there references to the object). Could someone that know's put it back in if deserved? Tenbaset 07:01 11 Jul 2003 (UTC)
- Well, as I understand it, that's exactly how Java garbage collection works: when an object reference is allocated on the stack (as a local variable), the object is collected when the stack frame is popped. In other words, when flow of the program goes out of the scope in which the local object reference variable was defined, the object pointed to by that reference is garbage-collected.
- Now, maybe a clarification is in order. When I wrote that, my intent was to point out that, to the programmer, autoreleased objects behave exactly like Java objects. The internal implementation is different, of course. (Cocoa's simple reference-counting system is far more efficient, and therefore faster, than Java's bizarre and inscrutable maze of algorithms, but I omitted that for obvious reasons. This is an encyclopedia entry, not a marketing brochure.)
- What do you think? Restore, clarify, or omit?
- Jharrell 12:38 11 Jul 2003 (UTC)
- The thing is that the description of autorelease objects doesn't agree perfectly with how Java objects behave. When an object reference goes out of scope in Java, the object only might be collected. Two reasons, firstly the GC doesn't guarentee any timeleness (appears true for autorelease pool as well); secondly the object will not be reclaimed if there are other references to it. (So, if I allocate an object with a reference on the stack, and then assign a reference to the same object in a non-stack variable, the object will not be collected until that, and all other references, have gone.) I got the impression (possibly inocorrectly) that Autorelease pool based objects are always reclaimed as soon as the scope is exited - even if there are references to the objects elsewhere. Tenbaset 10:55 12 Jul 2003 (UTC)
I un-did some of Tenbaset's edits. Here's why.
- Tenbaset said, "It contains functionality with which programs can create and interact with graphical user interfaces." I changed this back to "code," because "code" is literally correct while "functionality" is not. Libraries contain code, in the form of compiled functions, with which programs can do things. "Functionality," being an abstract sort of idea, isn't something that something can "contain." Plus, "functionality" is a weasel word. If we want to change this to "functions," I'm amenable, but there's an argument to be made that these libraries contain more than just functions. So I used the generic term "code."
- Tenbaset said, "... classes for common tasks such as string and value manipulation, containers and iteration, distributed computing, event handling, networking, and other functions that are not directly tied to the graphical user interface." I changed it back to "things like." String and value manipulation is a task. The other things aren't. Containers are things. Iteration is a process performed with a container. And so on.
- I changed "stems from Coca's NeXTSTEP/OpenStep heritage" back to "reveals Cocoa's..." because the "NS" prefix isn't a new thing. It's a leftover thing that was present in NeXTSTEP. So I don't think it can properly be said to "stem from" anything. Also, fixed the spelling of Cocoa, and eliminated a sentence fragment.
I also changed a couple of other little things to better reflect the document's structure, and I got rid of the phrase "among Windows users" because there were just too many commas in that sentence, and that phrase didn't really add anything useful anyway. (Even though I wrote it. I know, I'm heartless.)
Jharrell 00:15 12 Jul 2003 (UTC)
- Perhaps not "contain" but the libraries "have" functionality. ("Functions" wouldn't be wise, because these libraries almost certainly have "Methods", and in some languages there is a clear difference, depending on POV.) "Code" (as a word) just seemed clunky to me.
- "Things like" I think that phrase doesn't suit the formal tone of an encyclopaedia, which is why I changed that. "Reveals" has a connotation that you're accusing Apple of doing a cover-up, which is why I changed that.
- As for DSO/DLL, what is the word that MacOS developers use? (Or do they indeed use multiple terms?) (What extension do these files have?) Tenbaset 10:55 12 Jul 2003 (UTC)
- I dig it. I still prefer the less stilted "things like," but that's just me. I think formal makes sense up to a point, beyond which it's just puttin' on airs, you know? After all, "Never use a long word when a diminutive one will do." Which is why "functionality" is on my list. ;-)
- On DSO/DLL... classic Mac programmers never really embraced the concept. The old ASLM (Apple Shared Library Manager) went ignored by practically everybody. (Open Transport used it, as I recall.) Some folks used CFM (Code Fragment Manager) instead, but not too many. More often, code resources were loaded with the Resource Manager for things like Photoshop plug-ins. Shared code wasn't a big part of Mac programming in the pre-Mac OS X period. Microsoft created a COM implementation for the Mac and used it in Office. A few other products also used it, like later versions of PageMaker. But that was about the extent of it. For the most part, Mac programs were just statically linked.
- Jharrell 15:24 12 Jul 2003 (UTC)
JavaMac 18:54, 17 September 2006 (UTC) 18:52, 17 September 2006 (UTC)Guys, maybe I am being too picky, but I found this page on Apple's site: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/WhatIsCocoa/chapter_2_section_6.html which points out that the NS prefix comes from OPENSTEP note NEXTSTEP, NEXTSTEP used NX. I also felt it was interesting that Sun had some involvement. What do you think? Should it be corrected?
- OpenStep may have been the first to use the prefix "NS", but it's pretty clear the prefix itself stems from the NeXTSTEP heritage. – Mipadi 21:22, 17 September 2006 (UTC)
- I don't think that's clear. It seems logical that it's NeXT-Sun. 18.104.22.168 20:54, 31 May 2007 (UTC)
- It's likely from NeXTSTEP, as most sources credit the naming scheme. – Mipadi 17:41, 1 June 2007 (UTC)
Becoming excessively detailed?
I feel this page is becoming excessively detailed for a general encyclopedia article. I am a huge fan of Cocoa myself, but even I am somewhat surprosed at the amount this article has grown recently, and with far too much stuff that really is only of interest to those who already know something about Cocoa. Those people will have far better references to work from than Wikipedia! I think there is an element of evangelism which is driving the page to become a bit over the top. I think all those who contribute here should start thinking about ways to cut it down without losing the essence of what the article is for, which is to get over the basic concepts and overview of Cocoa to the interested lay person. The other problem with the article being as long as it is now is that it's actually a bit dense and off-putting to read, which is achieving the opposite of evangelism. I think there is much that can be replaced with suitable external links to Apple's documentation. Graham 11:02, 17 Apr 2005 (UTC)
- I agree the article, while well-written, doesn't quite read like an encyclopedia article. Take this sentence for example. "Readers familiar with rapid application development (RAD) systems, like Visual Basic or Borland Delphi, may be struck by some of the parallels between their systems and Cocoa." This sounds like a textbook or website, but not an encyclopedia. When you started to use phrases like readers, let us review this and this, you can have the following options to do memory management (for God's sake readers are not writing a Cocoa app!), etc, it should smell bad, very bad. Of course, the tricky part is how to preserve good information; it is often harder to remove things than add. -- Taku 17:04, Apr 17, 2005 (UTC)
Why was the name of this article changed, apparently without consultation (if there was consultation, where did it take place? - I have most Apple-related articles on my watchlist and didn't get a chance to see anything about this). API stands for APPLICATION programming Interfaces. Cocoa is NOT an API, it's vitually a whole operating system, you can write anything from command-line tools to drivers to system services to plug-ins to preference panels to screensavers and yes, even applications. The previous title seems fine to me, though if this is related to the other discussion about naming conventions for Mac-related articles, then Cocoa (Macintosh) would be more appropriate.Graham 23:30, 27 Apr 2005 (UTC)
I am going to go through and do a bit of surgery on this article. I hope this will meet with folks' approval - the problem as I see it is that there is far too much detail and advocacy in the article. While I'm a big fan of Cocoa and use it daily in my work, I feel this article is not in the right vein. It needs to convey what Cocoa is, without getting carried away with trying to evangelise it. I'll be making the changes over the next day or two - give me chance OK? Graham 00:04, 19 May 2005 (UTC)
Acquisition date of NeXT
This article says December '96 but the NeXT article says early '97. What gives? WAvegetarian 21:48, 18 October 2005 (UTC)
- I found out in Christmas (of 96) but I don't think the rest of the world heard until early 97. WilliamJonShipley 10:32, 11 December 2005 (UTC)
- http://www.news.com/Apple-acquires-Next,-Jobs/2100-1001_3-256914.html dated Dec 20, 1996
- The December 20 date is correct for the announcement of intent. The merger was finally completed February 7, after regulatory approval and other issues were sorted out. http://www.thefreelibrary.com/Apple+Computer,+Inc.+Finalizes+Acquisition+of+NeXT+Software+Inc.-a019104632
- http://www.news.com/Apple-acquires-Next,-Jobs/2100-1001_3-256914.html dated Dec 20, 1996
I've been working on a wikibook which a beginners guide to programming with Cocoa. As I write this it's still just a very early first draft, with many typos and other inconsistencies. Hopefully some others will be interested enough to help out! Here's the link: . Graham 23:22, 29 January 2006 (UTC)
"...called Key-Value Coding (KVC). This permits a piece of data or property of an object to be looked up or changed at runtime by name"
Attributes can be created or deleted at runtime but the object must be specifically setup to work this way. This is how NSDictionary works (a hash based object).
The article does not say if Cocoa provides hook to register entities like filehandles to be monitored by the event loop. This feature is essential for the use of scripting language and their libraries. For example, POE in Perl can have its own event loop or register entities to an external loop (here Cocoa event loop) for monitoring. —Preceding unsigned comment added by 22.214.171.124 (talk) 09:22, Jun 30, 2006 (UTC)
It would be nice to include some information that regular end-users would find interesting and understandable. Like "cocoa apps run faster than carbon apps" or "Cocoa apps all use the same style buttons and font renderings" if that's true; I don't know. —Preceding unsigned comment added by Ephilei (talk • contribs) 23:37, 8 October 2007 (UTC)
- regular users shouldn't find anything interesting in that sense about an API.
Fair use rationale for Image:Cocoa dev screenshot.png
Image:Cocoa dev screenshot.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.
Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.
If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.
Is there any official word on the pronunciation, and should the phonetic version be added to the first line? I've always assumed it was pronounced "ko-ko", like hot chocolate, but I've heard "ko-ko-uh" or "ko-ko-ah" as well. — John 19:23, 27 February 2008 (UTC)
- it's ko-ko, listen to any keynote or demo —Preceding unsigned comment added by Petchboo (talk • contribs) 15:57, 5 March 2008 (UTC)
- why dont you add it? —Preceding unsigned comment added by Petchboo (talk • contribs) 14:35, 10 March 2008 (UTC)
- It's November 2008 and still nothing? There is a little bit of info in the Cocoa Touch article, which has a merge proposal but no discussion. I suggest a section on Cocoa Touch with a link to the main article, or a section on differences – there are many differences, although I am not familiar with them. —[semicolons]— 21:36, 20 November 2008 (UTC)
Typos in Rich objects section
"Using only the built-in features, one can write a text editor application in as few as 0 lines of code. With new controller objects, this may fall to zero."
Also, maybe an example of how you would write a text editor in zero lines of code might be .. illustrative.
- You can pretty much drop a text field on a window, and then it does pretty much all the basic things a real editor can do (fonts, colors, sizes, ruler, etc), except maybe saving. But I don't know that we need to put that in the article. --Thekmc (talk) 19:21, 5 March 2011 (UTC)
Cocoa Vs. Carbon
Could someone write a very detailed explanation of the difference between Cocoa and Carbon, and how they compare and contrast? I don't know much in that field. I think it would benefit people reading this article, especially if they are choosing one. Maybe make a "Differences between Cocoa and Carbon" page sometime? —Preceding unsigned comment added by Geek 2.0 (talk • contribs) 01:23, 29 October 2008 (UTC)
AppleScript Studio and Snow Leopard
The following sentence needs an update reflecting AppleScript changes in Snow Leopard: "AppleScript Studio, part of Apple's Xcode Tools makes it possible to write (less complex) Cocoa applications using AppleScript."(126.96.36.199 (talk) 15:12, 12 September 2009 (UTC))
The first sentence says that "Cocoa is one of Apple Inc.'s native object-oriented application program languages" but it is not a programming language, instead, it is a framework. Khatchad (talk) 05:22, 13 August 2010 (UTC)Raffi 8/13/2010
Cocoa apps aren't necessarily better
This remark seems like an opinion or original research: "For end-users, Cocoa applications are considered to be those written using the Cocoa programming environment. Such applications usually have a distinctive feel, since the Cocoa programming environment automates many aspects of an application to comply with Apple's human interface guidelines."
It's entirely possible for a Carbon app to behave exactly like a Cocoa app, or for a Cocoa app to be poorly written and exhibit inconsistent behavior. Mike Richardson (talk) 20:20, 6 November 2012 (UTC)
But in both cases, the developer has to do extra work to get it to be like that