February 16, 2009 at 17:20Objective-J, MacOS Technologies on the Web
In the article, I tried to consider the current state of things in the Cappuccino project, and the accompanying language Objective-J. The text is aimed at people familiar with programming technologies in OSX, I tried not to go into specific implementation details. Those who are familiar with Cocoa can understand them this way, while the rest will first have to understand the basics of Objective-C and Cocoa (or browse through tutorials on Cappuccino sites).
Objective-J essentially represents a partial implementation of the Objective-C runtime based on Javascript. Technically, the implementation consists of a Javascript preprocessor that, based on regular expressions, turns Objective-J into regular Javascript. The runtime also includes several functions (similar to the Objective-C runtime) for accessing low-level language concepts. So there are functions for creating classes dynamically, ivar list, adding new selectors. In essence, the class implementation parser turns the description into calls to precisely these functions.
In addition to the preprocessor and RTTI implementation, the basic functions of the language include casting Javascript types to Cappuccino types (something like a “free bundle” of Carbon-Cocoa). So you can call selectors for strings or arrays:
The next component of Cappuccino is the Foundation. At its core, it’s a copy of Foundation from Cocoa, apart from changing the NS prefix to the CP prefix. Mac programmers feel at home. Well, or almost at home - because the number of classes and selectors implemented in them is significantly less. The biggest problem at the Foundation is now with the documentation, since people without Cocoa knowledge come to try Cappuccino and find scantily described methods by which their code sometimes says much more than a documentary comment. The situation is complicated by the fact that to generate the API documentation in Cappuccino, an Objective-C parser from Doxygen is used, which simply stops at some places other than Objective-C syntax.
There are several patches in the bugtracker that extend the functionality of Foundation, but they are in no hurry to add them to the upstream. Perhaps because the authors of the patches must first sign the Contributor's License Agreement , in fact - an agreement to transfer all rights to the code to 280 North. This is not a problem (if you write a patch in the framework - in most cases you do not mind that you would do anything with it), but it scares away those programmers who do not want to mess with "paper tinsel", and creates queues from patches to upstream.
The situation with AppKit is basically identical to Foundation. The user interface classes adapt to the realities of the Web, which somewhat modifies them in the process. CPTableView is very lacking, an analogue of which in Cocoa performs all the tasks of implementing the table and list interface. There is no Key-Value Observing, along with it is an analogue of Cocoa Bindings, so data can only be transmitted through delegates. It is difficult for programmers not familiar with Cocoa to understand the model of positioning views (there is even a separate tutorial on this topic). In general, the layout of the interface takes a lot of time. At the experimental stage, nib2cib is located - a converter of nib and xib files (interface descriptions from Interface Builder) into the native Cappuccino format. Of course, through IB to design an interface is simpler and more familiar, but firstly, the result is alwaysYou have to significantly modify the file, and secondly, only OSX users have Interface Builder.
Recently, the situation with Cappuccino is improving. The bugtracker is being put in order, the documentation on the basic concepts of the language is being improved (for ordinary html / css / js web developers). Potentially - behind Cappuccino there are ample opportunities. Even now, creating rich Internet applications on Cappuccino is in many cases easier than on js toolkits oriented for this (for example, Bindows).
Objective-J essentially represents a partial implementation of the Objective-C runtime based on Javascript. Technically, the implementation consists of a Javascript preprocessor that, based on regular expressions, turns Objective-J into regular Javascript. The runtime also includes several functions (similar to the Objective-C runtime) for accessing low-level language concepts. So there are functions for creating classes dynamically, ivar list, adding new selectors. In essence, the class implementation parser turns the description into calls to precisely these functions.
In addition to the preprocessor and RTTI implementation, the basic functions of the language include casting Javascript types to Cappuccino types (something like a “free bundle” of Carbon-Cocoa). So you can call selectors for strings or arrays:
objj> ["test" length] 4 objj> [[1, 2, 3] objectAtIndex: 1] 2
The next component of Cappuccino is the Foundation. At its core, it’s a copy of Foundation from Cocoa, apart from changing the NS prefix to the CP prefix. Mac programmers feel at home. Well, or almost at home - because the number of classes and selectors implemented in them is significantly less. The biggest problem at the Foundation is now with the documentation, since people without Cocoa knowledge come to try Cappuccino and find scantily described methods by which their code sometimes says much more than a documentary comment. The situation is complicated by the fact that to generate the API documentation in Cappuccino, an Objective-C parser from Doxygen is used, which simply stops at some places other than Objective-C syntax.
There are several patches in the bugtracker that extend the functionality of Foundation, but they are in no hurry to add them to the upstream. Perhaps because the authors of the patches must first sign the Contributor's License Agreement , in fact - an agreement to transfer all rights to the code to 280 North. This is not a problem (if you write a patch in the framework - in most cases you do not mind that you would do anything with it), but it scares away those programmers who do not want to mess with "paper tinsel", and creates queues from patches to upstream.
The situation with AppKit is basically identical to Foundation. The user interface classes adapt to the realities of the Web, which somewhat modifies them in the process. CPTableView is very lacking, an analogue of which in Cocoa performs all the tasks of implementing the table and list interface. There is no Key-Value Observing, along with it is an analogue of Cocoa Bindings, so data can only be transmitted through delegates. It is difficult for programmers not familiar with Cocoa to understand the model of positioning views (there is even a separate tutorial on this topic). In general, the layout of the interface takes a lot of time. At the experimental stage, nib2cib is located - a converter of nib and xib files (interface descriptions from Interface Builder) into the native Cappuccino format. Of course, through IB to design an interface is simpler and more familiar, but firstly, the result is alwaysYou have to significantly modify the file, and secondly, only OSX users have Interface Builder.
Recently, the situation with Cappuccino is improving. The bugtracker is being put in order, the documentation on the basic concepts of the language is being improved (for ordinary html / css / js web developers). Potentially - behind Cappuccino there are ample opportunities. Even now, creating rich Internet applications on Cappuccino is in many cases easier than on js toolkits oriented for this (for example, Bindows).