I know bill Pugh is thread safe and recommend way to use.
I searched a lot about it in the internet but couldn't find an answer.
is bill Pugh solution will work on objective c as well ?
I know it will work on java, but do some of you have experience in objective c?
Had to look up The "Bill Pugh singleton".
Sure, it could be used in Objective-C, but why bother? There is already a perfectly good singleton pattern in wide use in ObjC (that largely implements the same pattern anyway; the singleton is only created on first access).
Related
Learning basic Objective-C and have a few beginner questions.
How would I define and implement a method which takes two (or three) arguments within my class?
I find the syntax to pass multiple arguments into a method really confusing. I would really appreciate any help. thanks.
Apple's "The Objective-C Programming Language" document provides a nice overview of Object Messaging including an explanation of the syntax.
Here's an example of a simple 2-argument method implementation:
-(int)myMethodThatMultipiesThisNumber:(int)x byThisOne:(int)y
{
return x * y;
}
You would invoke it like:
int z = [myObject myMethodThatMultipliesThisNumber:6 byThisOne:9];
Is that what you're looking for?
Edit: Based on your comment below, it seems like you're missing a fundamental feature of Objective-C messaging - that the method name is interleaved with the arguments. Check out this page from The Objective-C Programming Language for all the detail you need.
Whether or not you are interested in iPhone programming, I would watch the first three classes of Paul Hegarty's CS193P class from Stanford.
Those first three classes have very little iPhone specific stuff, instead, classes 1 and three go over the features and syntax of Objective C, and class 2 goes over basic use of Xcode (which, if you want to do Objective C work, is likely the IDE you will be using). Other than the fact that it goes VERY fast (which may actually be what you are looking for) you would be hard pressed to find a better "quick overview" of Objective C.
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 was coding some stuff on objetive c.. but I still dont get it, I dont know/understand what a delegate is at all.
Maybe cuz my main programming language is C++ and Java... dont know.
I searched the web looking for an ENGLISH explanation, but, seems like I dont speak english :)
A delegate is an instance of an object that implements a bunch of what C programmers call callbacks, but in an object-oriented way. Like most new concepts, it is really just an old convention renamed and obfuscated.
There are some nice examples here on wikipedia.
In Objective-C, a delegate is an object that conforms to a specific protocol, that another object can rely on for specific functionality. It's a different concept to delegation in lots of other languages, and it can get confusing because the terminology is the same.
Here's an article I found rather useful when I started programming in Objective-C:
http://developer.apple.com/mac/library/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html
This question is about variable naming style in objective c and cocoa. I just want to stress that I'm not looking for a "right" answer, just good ideas.
I've read through Apple and Google's objective c style guides and I'm not really happy with either of them. Apple's guide doesn't have any real style recommendations regarding instance variables vs local variables. In fact, the Cocoa library itself seems perfectly happy having function parameters of the exact same name as instance variables. That makes me cringe personally.
Googles guide specifies that instance variables should be indicated with a trailing underscore. Alright, all well and good, but it suggests that we then synthesize every public property with #synthesize property = property_. I don't know about anyone else, but I'll be damned if I'm going to do that for every instance variable in my project. I think it's a wasteful and confusing solution.
I'm tempted to go with the myX (eg "myInstanceVariable") naming style for object properties, but I have rarely seen that style in objective c.
So yeah, what do you use? Any style conventions out there I don't know about that you've found useful? Do you think function parameters with the same name as instance variables is dangerous, especially in multiple developer environments? Thanks guys and gals!
NOTE - As many people have pointed out, my terminology was off in the OP. Apologies if the original wording hurt the clarity, but I think the point was still clear.
I tend to use non-prefixed instance variable names (note that "member variable" is a C++ism as it's suggestive of structures and classes being mainly interchangeable, which is not the case in Objective-C), and in cases where ambiguity arises, I use the Smalltalk convention of naming the parameter by its type with "a" or "an", e.g.:
- (void)setFoo:(SOFoo *)aFoo;
{
foo = aFoo;
}
(of course, in modern ObjC you'd use a property for this.)
Using theFoo instead of aFoo is also somewhat common; see the answers to this question.
The Google convention makes sense if you're really worried about conflicts. If you use an Xcode text macro or tool like Completion Dictionary or Accessorizer to generate your directives, it's pretty simple to adopt.
Note that the Cocoa key-value coding guidelines pretty much assume either (a) you do not prefix/suffix your instance variable names, or (b) you implement (or synthesize) non-prefixed/suffixed accessors for them. As someone else mentioned, do not use the _ prefix; it's reserved for Apple's use in their frameworks.
First: there are no "member variables" in Objective-C, there are "Instance Variables" or "ivars".
Google is NOT any kind of authority on Objective-C coding or Mac development. Google Earth is a Qt app: 'nuff said.
I seem to remember seeing an official coding style guide from Apple for Objective-C, which I'm not finding at the moment. This article is a pretty good summary, though:
http://cocoadevcentral.com/articles/000082.php
Found it! Here's Apple's official coding guidelines for Cocoa:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html
In Cocoa, the style is to have pascalCased (or is that camelCased? I can never remember) names; and have the member variables be named the same as the accessor methods. (Such as NSInteger anInteger, - anInteger and - setAnInteger:).
It might not be the best style, but it's probably a good idea to get used to it if you are going to do any amount of work with Cocoa, as a number of mechanisms assume this particular kind of naming convention.
_foo is not bad habit. Or at least it is not anymore. See:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html
m_variableName is pretty common too for member variables.
Personally, most of the time, I just go with the same name for both variables and making the distinction between this.varname and varname.
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.