By now, most of your are familiar with our announcement that the Perian team is retiring. It was a long time coming, but still a sad day none the less. I can see that the community reaction is that of disappointment as well. Perian was so quiet in its arrival that I never stopped to realize how loud its departure may be. So I decided to recount my history with the project, through its trials and its joys. It was a wonderful ride, but now we leave it behind and ride off into the sunset.
This is one past the last is a series of blog posts I’m writing on things that Objective-C can learn from Java. I’m writing this because I’m seeing a series of ignorant tweets stating how much Java sucks. The other parts can be found here:
Anyone who programs in Java for a short period of time becomes well aware of Java’s exceptions. To the new programmer, they may be a bit of an annoyance, but to anyone designing enterprise-level code, they are a necessity. Objective-C has exceptions too, but they are so weakly defined in the language and so overlooked, it’s almost as if they were nothing more than an afterthought. In fact, one can argue that the exception handling in C++ is superior to what one would find in Objective-C.
This is the last is a series of blog posts I’m writing on things that Objective-C can learn from Java. The other parts can be found here:
For one who has programmed in other object oriented languages, Objective-C stands out with its complete lack of namespace. As a result, classes have a prefix, such as Apple’s common NS and UI prefixes. On the mac side of things, every class under the sun seemed to start with NS, such as NSString, and confusion is added when on the iOS side, several classes start with UI, such as UIView. This is due to the fact that without a concept of namespace, Objective-C cannot have two classes with the same name, regardless of whether the classes are public or not.
This is the third is a series of blog posts I’m writing on things that Objective-C can learn from Java. The other parts can be found here:
Objective-C still retains a lot of its heritage from it’s C beginnings. This includes using two files, a header and a source file, for each class. In a strictly object oriented environment, the header file contains the class definition (super-class and instance variables), public property definitions, and any public function declarations. The source file contains all of the function implementations, including synthesize statements. In contrast, Java contains all the functions of both files in a single file. To one who knows better, as in one who has used the single file environment, the two files for each class becomes a pain.
This is the second is a series of blog posts I’m writing on things that Objective-C can learn from Java. The other parts can be found here:
When one is using object oriented design, a common practice is to lump similar classes together with a common super-class and include the common functionality in that super-class. In doing such design, a common problem is for the super-class to require some information that can only be computed by the sub-class. The solution is for the super-class to make a function call on itself which the sub-class implements. For example, I recently designed a class which simplifies storage of an object in a SQL row, but it knows nothing about the actual field names or values stored in the database. In this case, I made a function, which subclasses implement, to retrieve this data. In Java, this is simply done through an abstract method in an abstract class.