Shocking Objective-C for Java Programmers, Part Two

I continue the short review of the features of Objective-C, surprising Java programmers (the first part ). In the second part a little will be told about the philosophy of the language, about the support of namespaces and the type of id . Judging by the comments to the first part, it is necessary to philosophize a little, therefore, the promised properties ( property ) are transferred to the third part. Also find out what questions are asked in American supermarkets.

Perfection is not when there is nothing to add, but when there is nothing to take away

')
As bobermaniac correctly noted in the comments to the first part - the syntax is not very important, it is more important to understand the idioms of the language. It is equally important to understand the general principles of constructing a language, its philosophy. The very shiver takes from the highness.

I started with a hackneyed quote, but it perfectly characterizes the design of the C language. Simplicity, expressiveness, brevity, and all this without sacrificing opportunity. The creators of C believed in people - as a result, the last one always wins in the dispute between the compiler and the programmer (although not always the end user is happy about it). But then programmers wanted to work with objects. And on a compact foundation with planted columns object orientation. The most successful in this is C ++. But formally using C as the basis, C ++ does not follow its minimalist spirit. The difference in the thickness of the "Kernigan-Ritchie" and "Straustrup" is suggestive.

Brad Cox wanted to add the SmallTalk features in C without creating a completely new language. He did it and Objective-C created by him is a superset of the C language, preserving the spirit of its design in object extensions. Those. C is left as it is, object-oriented innovations are made within clearly defined boundaries and not so many. In part, does this explain the unfamiliar Objective-C syntax? All of these [] and @ are those yellow ribbons that enclose the construction area (or do they only hang yellow ribbons at the crime scene?). One characteristic example of minimalism is that in Objective-C there is not even a special syntax for creating objects, nor is it for defining a constructor and a destructor. The methods alloc, init, new, dealloc are not part of the language, but part of the framework.

The creators of Java went a little different way and focused on the security of the language, introducing more stringent type checking, checking the output of the array, mandatory processing and specification of exceptions, and much more. Belief in man was replaced by faith in a soulless compiler. Therefore, it is very important for Java programmers to remember that Objective-C, like C, limits the author much less, often at the expense of code security. I’m not even talking about memory management, but such language features as categories, exceptions unchecked by the compiler, informal protocols, no guarantee of the method’s existence (not always, but it happens). If you wish, you can shoot with two hands on your legs.

Now, let's follow the Java programmer who is looking around at his side and consider a couple of practical questions.

Do you have id?

A similar question can be heard when buying alcohol in North America. In response, an identity card with age information (usually a driver's license) should be shown. I heard the “idea” for the first time in a question and answered with surprise that I was going to drink all 6 bottles of beer without any ideas. The seller cautiously pulled the packaging towards him.

In Objective-C, there is also an id type - a universal reference to an object of any class. If a Java programmer thought that this resembles a reference to an Object , then he is mistaken. If the programmer thought that this resembles void * , then he is mistaken. The compiler treats id exactly as a reference to an object of any class. You can call any previously defined method of any class (but if the method is not defined, you cannot), assign an object of any class without type casting, etc. The only restriction is that you cannot access the fields of objects.

I will remind once again the structure of classes from the previous article.

@interface Profile : NSObject @property (readonly) int version; @end @interface Feature : NSObject - (Profile*) getProfile:(NSString*)name; @end @interface Phone : NSObject + (Phone*) designAndProduce:(NSString*)name; -(Feature*) getFeature:(NSString*)name; @end 

Now a few examples of using id:

 //   id idPtr = [Phone designAndProduce:@"iphone5"]; //    Phone* anotherPhone = idPtr; //    (     ) Feature* badFeature = idPtr; //   -  ,   getFeture      Feature* anotherBadFeature = [idPtr getFeture:@"bt"]; //    Feature* btFeature = [idPtr getFeature:@"bt"]; //   ,  ,   ,   Profile* profile = [idPtr getProfile:@"a2dp"]; 

In the latter case, when you start the program, we get the error message: Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '- [Phone getProfile:]: unrecognized
and begin to understand a little better how message dispatching works.

Plastic or paper?

Another good question from the cashiers of American supermarkets. They ask what kind of package to give, but from the first time very few people guess.

So, about the packages. Unpleasant news for Java programmers - packages ( packages ) are not here. There are no namespace management mechanisms at all. You can only choose which header files to include and which not. Say thanks to the minimalism of C and the conservatism of the authors of Objective-C. To avoid name conflicts, the use of prefixes is recommended. For example, NS in the class name NSObject is a prefix of classes developed for NeXT's NextStep OS. The latter was founded by Steve Jobs in between work at Apple and work at Apple.

We need to remember one important difference from Java. All classes of the Java platform are available to the JVM, all classes added by the user to the classpath and / or lib / ext and something else. Therefore, name conflict is very difficult to avoid. An Objective-C program deals only with the classes used in the code, so the probability of a conflict is an order of magnitude less. This is due to the different import semantics in Java and #import in Objective-C. The first imports the namespace, allowing the use of short class names in the code. But the class itself is available without it, you just have to write the full name of the class (ie, not List , but java.util.List ). In Objective-C, a real import of a class definition occurs; without it, the compiler has no knowledge of this class.

Sometimes a half-measure is useful — the @class directive allows you to declare a class without defining it.

 @class Profile @interface Feature : NSObject - (Profile*) getProfile:(NSString*)name; @end 

In this case, we assure the compiler that such a class exists and he agrees to compile our code. Because the compiler still does not know anything about the structure of the class, sending messages to objects of this class will cause a compilation error. But this is usually not necessary, because The directive is usually used in header files. The question arises - why is it needed at all if you can do with #import ? Usually to optimize compilation in large projects, since import can greatly increase the amount of code and, accordingly, the compilation time. The second reason is cyclic links between classes.

Conclusion

I hope the only question left after reading is - what is the reason for American supermarkets? I do not know, just such subtitles turned out.