I would like to start programming on Mac. Please:
I don't really like Objective-C and I somewhat know C, I read that Objective-C is a "dialect" of C - is it possible to program in C and use all the libraries and frameworks provided by Mac OS (this is Cocoa, right?)?
is it possible to draw GUI in XCode's GUI Builder and then fill the logic in plain C?
if I want to use, say, Scintilla - how do I "load" its text editing component into a window in GUI builder? And how do I access its text buffers? And events?
Just learn Objective-C. It isn't that hard; much, much, simpler than, say, C++. The object model is extremely similar to Java or SmallTalk.
The entire Cocoa stack of APIs are all in Objective-C, the documentation is all in Objective-C, many of the design patterns (KVO, KVC, delegation) are inherently Objective-C isms and all of the examples are Objective-C.
You are going to have to have a working knowledge of Objective-C to effectively program the system anyway. Any attempts to avoid Objective-C is just going to make your job harder, yield less maintainable code, and vastly reduce the # of folks in the community who can help.
Sure, by interacting with the runtime directly. It means you'll be doing a lot of objc_msgSend() et al. It's going to be horribly painful, you might as well just learn the Objective-C syntax and be done with it. (I explicitly note the syntax, because you will still need to learn the way objc does things in order to even use the C APIs).
The bit I can be least helpful on first: without having heard of it, according to its website Scintilla is for win32 and GTK+. As I believe that there's still no Cocoa native version of GTK+, there is no way to use a Scintilla component in a Cocoa program. OS X is not based on X11 (or Win32, for that matter).
Objective-C adds Smalltalk-style objects and dynamic dispatch to C. However, it is a strict superset, so C code is directly callable. The various GUI components rely on the dynamic, reflective nature of Objective-C so cannot directly call C code. However, the whole toolkit is built around the model-view-controller paradigm. It is quite feasible to design your view in Interface Builder, write a thin shim of a controller in Objective-C that does little more than call appropriate C functions and write your model entirely in C. C code can call Objective-C code, so you can wrap as many of the system objects as you want.
So this i pretty much a 'yes' to your second bullet point. Also relevant is that although Objective-C springs from C, Apple have made C++ fully callable (search for Objective-C++), so that's also an option.
Well worth looking into is Core Foundation. OS X originally supported two top-level programming environments — Cocoa and Carbon. Cocoa is Objective-C, Carbon is C with a bunch of legacy support libraries (and is now deprecated, with no 64 bit runtime to be supplied). To support both of these, much of the core system functionality is exposed through C interfaces at the lowest level, including all collections, strings and other relatively primitive objects. A bunch of other performance critical things like Core Text, Core Graphics, etc are also normally done via a straight C interface, even if you're otherwise completely enthusiastic about Objective-C.
There is a C-based API for UI programming on Mac OS X called Carbon. If you really cannot stand the sight of Objective-C I would start there. Many Cocoa classes and APIs have corresponding Carbon datatypes, etc. and vice versa but not all of them. Fair warning, Carbon is considered a "legacy" API, and it will likely continue to be marginalized as time goes on. Many Carbon APIs are not available for 64bit applications for example
Cocoa specifically is an Objective-C based API, using it from C would be awkward and difficult if possible at all. It would require some knowledge of Objective-C runtime APIs and possibly internals or otherwise writing a bunch of wrappers.
Related
I'm trying to understand why there exists both CF and NS objects, which seem to do the same thing and are interchangeable through toll-free bridging. If, say, CFArray and NSArray do the same thing, and I can cast between them freely, what's the point in both of them existing? Are there rules of thumb about when to use one over the other? Are the CF objects just legacy objects from old frameworks? Any insight into this would be greatly appreciated.
To answer your questions in order:
What's the point of them both existing? There are a few reasons.
If you want to provide a C API, like the Carbon API, and you need things like arrays and dictionaries of referenced-counted objects, you want a library like Core Foundation (which provides CFArray), and of course it needs to have a C API.
If you want to write libraries for third-parties to use on Windows (for example), you need to provide a C API.
If you want to write a low-level library, say for interfacing with your operating system's kernel, and you don't want the overhead of Objective-C messaging, you need a C API.
So those are good reasons for having Core Foundation, a pure C library.
But if you want to provide a higher-level, more pleasant API in Objective-C, you want Objective-C objects that represent arrays, dictionaries, reference-counted objects, and so on. So you need Foundation, which is an Objective-C library.
When should you use one or the other? Generally, you should use the Objective-C classes (e.g. NSArray) whenever you can, because the Objective-C interface is more pleasant to use: myArray.count (or [myArray count]) is easier to read and write than CFArrayGetCount(myArray). You should use the Core Foundation API only when you really need to: when you're on a platform that doesn't have Objective-C, or when you need features that the Core Foundation API provides but the Objective-C objects lack. For example, you can specify callbacks when creating a CFArray or a CFDictionary that let you store non-reference-counted objects. The NSArray and NSDictionary classes don't let you do that - they always assume you are storing reference-counted objects.
Are the CF objects just legacy objects? Not at all. In fact, Nextstep existed for years with just the Objective-C Foundation library and no (public) Core Foundation library. When Apple needed to support both the Carbon API and the Cocoa API on top of the same lower-level operating system facilities, they created (or made public) Core Foundation to support both.
Incidentally, some of Core Foundation is open source. You can find the open source part of it for Mac OS X 10.10.5 here: https://opensource.apple.com/source/CF/CF-1153.18/. I have found the source code of CFRunLoop and CFStream to be very informative.
Core Foundation is a C API to a variety of common data structures. Most of these data structures have equivalents in Cocoa, but not all of them. Most of the ones that are equivalent are toll free bridged, allowing them to be used interchangeably, but not all of them either.
Toll free bridging is a very clever implementation trick. If you want the underlying details, see the ridiculous_fish post that #Matt Wilding points out. It's the most authoritative on the subject (and a major influence on iOS:PTL chapter 19 which also explains how it all works). But it doesn't really matter for most purposes. As Matt notes, you can generally pretend that an NSArray is the same as a CFArrayRef. This isn't really true in many cases, but it's sometimes true, and close enough most of the time. It's the same as saying that #"stuff" is the same as an NSString containing stuff. It's mostly true, but not exactly.
When OS 9 moved to OS X, it was very convenient to provide C access to Objective-C-like data structures. Many low-level frameworks today expose C APIs for performance reasons. You shouldn't think of CF as "legacy" or "internal." You should think of it as low-level and you should only use it when you need the power it provides, or are dealing with a low-level framework that requires it.
CF objects are often more flexible than their NS counterparts. For example, CFDictionaryRef can contain non-object keys and values, while NSDictionary can't. (Of course they're toll-free bridged, so you can create a non-retaining CFDictionaryRef and then treat it as an NSDictionary. Tricky that....)
As Apple releases new frameworks, you'll notice that they often expose C APIs first, and then later add Objective-C APIs. This is a reason that it's a good idea to learn Core Foundation, even if you don't use it every day. But when possible, you generally should be using ObjC.
There's some history to this question. Core Foundation is the brains of the operation. It's written mostly in C. It was created with Apple's acquisition of NEXT and their APIs and owes a lot to them. The NS* classes are often just Objective C abstract interfaces built on top of the CF* types. So, when you ask why both CFArray and NSArray exist, the answer is that they actually don't. NSArrays are CFArrays, NSStrings are CFStrings, etc. That's why toll-free-bridging is possible.
For more interesting and detailed reading, I would refer you to this blog post.
CF stands for CoreFoundation. Exposed objects with CF in their names are just regular Core Foundation objects, written in C. All objects are toll free bridged with their Cocoa Touch Foundation friends over in Objective-C land. They are usually opaque pointers.
NS stands for NextStep, which was the old OS that Mac OS X was built upon. NS-prefixed objects are usually written entirely in Objective-C or C or even some C++.
It really depends on what you need each object to do. It's certainly easier for me to work in pure Objective-C with NSString, then it is for me to work in a mix of C and Objective-C with CFString, but there are some things that CF objects can do that NS objects simply can't (mostly very low level stuff). CF objects also dabble a lot more in Ref's, mutations, and inspections than their NS counterparts.
(For future reference, there exist a few more prefixes: CG for CoreGraphics, UI for UIKit, QL for QuickLook, AV for AVFoundation, MP for MediaPlayer, MF for MessageFoundation, GL for GLKit, and MK for MapKit)(If I've missed any, I'll gladly edit).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Objective-C is an object-oriented programming language that adds Smalltalk-style messaging to the C programming language. I understand that learning Smalltalk might be good in the same way that learning Lisp is good for one's knowledge, but I want to know if learning Smalltalk-specific concepts will help me to understand Objective-C more completely, given Smalltalk's role in its "origin story". If so, what specifically?
Assuming that one already knows C programming, what can we learn from Smalltalk? Obviously, there's a lot of concepts in Objective-C that just aren't in C (ie. messaging, interfaces, protocols, dynamic typing, delegation, reflection; it's object-oriented!) but are derived from Smalltalk.
Edit: I've added the C programming language to the question, as the general consensus is that learning C is a better use of one's time than learning Smalltalk (when it comes to programming in Objective-C).
Smalltalk is an incredibly compact language and remains one of the most pure object oriented languages. Objective-C is a pragmatic compromise between Smalltalk and C, which makes for some very substantial differences. For example, in Smalltalk everything is an object — even simple numbers — and every manipulation of an object is by message sending. Messages are evaluated in the same order irrespective of their name. So e.g. the following:
8 + 9 / 23 + 16 * 8
Is evaluated in strict left-to-right order because the operators '+', '/' and '*' have no special meaning to the language being just messages that are passed on to number objects.
Objective-C adds Smalltalk-style objects to C but is also a strict superset of C that retains C's primitive types and built-in operators. So in Objective-C the normal mathematical order of operations would be applied to the expression above — the division and the multiplication would be done first, the additions afterwards.
Learning C is absolutely essential to a thorough understanding of Objective-C. Objective-C is a strict superset of C and explicitly uses exactly the same syntax and semantics as far as they go. It grafts the concept of objects onto C by virtue of C's ability to retain a pointer to a thing without knowing how to apply any operations to the thing. It then extends the C syntax to provide a means for posting messages to objects and for declaring and implementing the messages an object may receive.
A lot of the general design of the Objective-C runtime, especially when coupled with Cocoa, comes directly from Smalltalk, including the concept of a selector, the use of metaclasses as factories for instances of classes, the hierarchy and system of inheritance, the division of model-view-controller (a Smalltalk original, albeit now almost ubiquitous) and a lot of the messages defined on the standard collections and objects.
Off the top of my head, Smalltalk also differs greatly in its system of flow control and has a similar but subtly different idea of a 'block' (though most newer implementations have brought the two into line). Apple have actually implemented blocks as an extension at the C level which is utilised by a lot of the newer methods on Objective-C objects.
That all being said, the Goldberg Smalltalk-80 book is extremely well written, easy to read and the language is so simple that you can learn the whole language in just two or three chapters. Most of the complexity is swallowed by the objects available in the runtime, and obviously that stuff doesn't transfer. The benefit to you is that the ideological stuff about objects and runtimes ends up very separated from the specifics in print. Conversely, C makes stuff like flow control and arithmetic a language feature, which means more syntax and more to read before you really feel you know what's going on.
So, in conclusion: the Smalltalk-80 book (the purple one) is definitely worth a read and extremely helpful but not necessarily entirely relevant. Learning C is essential in any case; my references to K&R are for comparison.
From Smalltalk you can learn real object-oriented programming. Hybrids like java, c# and Delphi don't seem to do so well. After ten years of hybrids, my coding style significantly improved after a few months of Smalltalk.
As an iPhone developer, you're probably more interested in the design of the libraries and the concepts used than the syntax. c is not going to be any help there (though you need to understand some basics). Programming in Objective C feels much more similar to programming in Smalltalk. The Smalltalk IDEs are far superior to the Objective C ones, and help you understand much better how object-oriented code works, and how to build it. It is much easier to keep your code clean and well-refactored in a Smalltalk (IDE) than in any other object-oriented language. The cocoa libraries are very well designed, at least when compared to the java or .net ones. They seem to be in somewhat better shape than e.g. the Squeak Smalltalk ones.
I have to disagree with Knodel just an example see this
[someObject message]
and see
someObject message.
You see Objective-C uses the same "positioning" and yes it comes from Smalltalk.
Learning Smalltalk is always a good investment of time. And the meaning in this area is 100% smalltalk send some message to either an Object or an Class which itself has some MetaClass.
And yes learning C is good to know how to use part of Objective-C but getting used to OO is not taught by C. So knowing C and Smalltalk makes it easier to use Objective-C. BUT Objective-C is not just the language the "power" comes from the class libraries. So spending time on that is surely good spent time.
And yes you better knew C and Smalltalk to make the best out of Objective-C.
Disclaimer: I don't know Smalltalk.
I'm sure your Obj-C skills would benefit from learning Smalltalk, but in my opinion, your time would be much better spent learning C. As someone who learned Obj-C before delving into C, the concepts taken from Smalltalk are easy to pick up, the concepts taken from C are much more difficult.
Yes, the Objective parts of Objective-C are very similar to Smalltalk. If you learn Smalltalk first, some of the concepts of Objective-C will be easier and the syntax of sending messages will be less of a shock. However, I don't think Smalltalk is necessarily any easier to learn than Objective-C, certainly not if you know C already, so you might as well learn Objective-C straight off.
Having said that, Smalltalk is a nice language IMO and worth learning for its own sake.
I think that the best background to learn Objective - C is C. If you know C, you'll easily become familiar with object-oriented programming and write in Objective - C.
Personally, I don't think learning Smalltalk us a good idea.
Getting used to passing messages to objects instead of calling methods is pretty easy without a SmallTalk background. However, SmallTalk doesn't look anything like C (except for the SuperCollider variant) and the language even treats code blocks and other crazy stuff as first-class objects: e.g. in SuperCollider {i < 5}.while({ // do stuff }) This behavior did not come over to Objective-C and will likely just confuse you as it does me.
I have some maybe stupid question. What is the difference between C++ and objectice-c. Is there IDE for objective-c for linux ?
I'm going to expand a bit on DaVinci's point 1.
First the similarities:
Objective-C and C++ were both originally based on C. Both languages support an object oriented model. That's where the similarities end.
Objective-C is a strict superset of C, C++ is not. Any C program is also an Objective-C program. This is not necessarily the case with C++.
The syntax of Objective-C's OO extensions is closer to the syntax of Smalltalk than that of C whereas the reverse is the case with C++.
The philosophies behind the OO models is completely different too. Objective-C's model is dynamic in the spirit of Smalltalk. C++'s model is more static. With Objective-C, you send messages to objects and the object decides at run time how it is going to respond to the message. With C++ the methods that an object responds to - even the virtual ones - are defined at compile time. This makes Objective-C's object model immensely more powerful than C++'s object model. For instance, you can add whole sets of new methods to existing classes without using inheritance. You can even replace method implementations on the fly.
This all comes at a cost of course. Sending messages to Objective-C objects is quite a bit slower than calling C++ virtual functions. However, I think the benefits are worth the cost and you can always drop back to C for performance critical sections of code.
NB there is also a language called Objective-C++ which is the Objective-C OO extensions built on top of C++ instead of C.
they are simply two quite different languages.
I think gnustep is the only objective-C environment/library, it also has a IDE: project center, however Objective-Cs home is primarily on Apple products.
Hi I'm writing this question because I'm a newbie in ObjC and a lot of doubts came to my mind when trying to make my fist training app. The thing is that I have a strong background in C, I've been programming in Java for the last year and I've done some collage stuff with Smalltalk (I mencione this because those are my programming references and those are the languages I'm comparing ObjC with).
The first problem I've encountered is that I don't know where to draw a line between ObjC and C, for example when dealing with math operations, Should I use math.h or there is a more "object-way" like you can do in Smalltalk (aNumber raisedTo: 3) ? How does a person with no background at all in C learns ObjC?.
Another thing that I couldn't find was a collection's protocol (I've looked over the Foundation Framework documentation given by Apple). Because I want to implement an expresion tree class and I wanna know if there are methods that all collections should implement (like in Smalltalk or Java) or I gotta check by hand every collection and see if there is a cool method that my new collection should have.
I don't know if I'm being too stupid or I'm searching for features that the language/framework doesn't have. I want to program in ObjC with the ObjC style not thinking in C, Java or Smalltalk.
Sorry if the question was too long.
Absolutely use <math.h>. You don't way to pay message sending overhead for functions that run in 30 cycles. Even function call overhead seems pretty steep at that point.
More generally, use as much or as little of C-style as you want to. I've seen Objective-C that was nothing but a couple C modules glued together with objective C messages, and I've seen Objective-C that essentially zero lines of code without the square brackets. I've seen beautiful, effective code written both ways. Good code is good code, however you write it.
In general, you'll use C features for numerical calculations. You'll generally use objects for most other things. The reason for this is that objects are way heavier than a simple scalar — there's just no benefit to it. Why would you ever write [[NSNumber numberWithInteger:1] numberByAddingNumber:[NSNumber numberWithInteger:2]] when you can just write 1+2? It's not only painful to read, it's far slower and it doesn't gain you anything.
On the other hand, Cocoa has rich object libraries for strings, arrays, networking and many other areas, and using those is a big win.
Knowing what's there — and thus what the easiest way to do something is — is just a matter of learning. If you think something should be there and you can't find it, you can ask either here or on Apple's Cocoa-Dev mailing list.
As for a collection protocol — there really isn't one. The closest thing to it is the NSFastEnumeration protocol, which defines precisely one method: countByEnumeratingWithState:objects:count:. This lets you use the for (id someObject in someCollection) syntax to enumerate the objects in a collection. Otherwise, all the collections define their own independent interfaces.
The first problem I've encountered is that I don't know where to draw a line between ObjC and C.
My rule is to use C wherever it makes sense to you. Objective-C has the benefit of letting you choose when to be procedural and when to be object-oriented. Go with what fits best with the code you're writing.
Another thing that I couldn't find was a collection's protocol [...] I want to implement an expresion tree class and I wanna know if there are methods that all collections should implement (like in Java) or I gotta check by hand every collection and see if there is a method that my collection should have.
Unlike Java, Objective-C does not have a master protocol for collections like the java.util.Collection interface. Also, there aren't a proliferation of specific container implementations as in Java. However, that gives you the freedom to implement a collection in a way that makes sense for your code.
For building a tree-like structure, you might take a look at NSTreeNode to see if it might be useful to leverage. (It may be more than you're need or want, but might be worth a shot.)
As far as rolling your own collection, I've learned a lot while creating CHDataStructures.framework, and you're welcome to use whatever you like from that code, or just look at my attempts at creating Cocoa-like structures, designed to complement the Foundation collections and operate similarly. Good luck!
Try to use each language for what it's good at. IMHO, this would include Obj-C objects but C-like code implementing methods. So use math.h and concise C code to implement logic, but don't be shy about using Obj-C classes to organize your larger blocks of functionality into something that makes sense.
Also, try to interact with the frameworks using their style so you're not running upstream.
As has been mentioned, there’s no real protocol for abstract collection classes (aside from the NSFastEnumeration protocol which provides the for(id item in collection) syntax when implemented), but there are conventions to follow.
Apple’s Introduction to Coding Guidelines for Cocoa covers some of this, and there is in fact a section on naming collection methods which covers the general cases (though note that generic container classes such as NSArray use the term “Object” as opposed to “Element” listed in the examples there – i.e. addObject:, removeObject:, and so on).
Following the patterns listed here (among others) is actually crucial when you want your classes to be KVC-compliant, which allows other users to observe changes in your object’s properties.
I'm just learning Objective-C/Cocoa programming for the Mac. All of the tutorials, books, blogs, podcasts, etc. I've been using really cover the two together. Is there an easy way to tell which pieces are vanilla Objective-C and which come from Cocoa?
Objective-C is the language... it defines all the things like the keywords for defining objects, the syntax for messaging object, things like that.
Cocoa is a development framework (it's actually an umbrella framework which combines three other frameworks, Foundation, AppKit and CoreData).
These frameworks (Cocoa) define all the objects that are nice to use and interact with the operating system, as well as a number of functions. For example, Cocoa defines things like NSString and NSObject. Cocoa can currently be used with other language bindings, such as python or ruby, and used to be used with Java as well. So, if you were using Cocoa with Java, you would still get an NSString object, but you would call and use it from within a Java application.
Without linking to one of the Cocoa frameworks, Objective-C comes with only a very basic Object class as a pre-defined root class.
Objective-C is the language itself.
Cocoa, formerly NextStep, is the API and runtime that sits on top of Obj-C. Anything starting with NS (for NextStep) is part of Cocoa, not part of the language.
Sure, it is quite easy - Objective-C is the language, Cocoa is the API/library you are using to build you Mac App.
Look in /usr/include/objc/ — in there is pure Objective-C. Everything else is Cocoa. You might notice you almost never directly use anything in there.
However, in practice it makes little difference. Cocoa is the de facto Objective-C standard library. The only platform where Objective-C is used without Cocoa is Portable Object Compiler, and I'm guessing maybe three people still use that.