Objective-J, MacOS technology on the web
In the article, I tried to examine the current state of affairs in the Cappuccino project, and the accompanying Objective-J language. The text is aimed at people familiar with the programming technology in OSX, I tried not to go into specific implementation details. Those familiar with Cocoa are understandable, and the rest will first have to figure out the basics of Objective-C and Cocoa (or look through the tutorials on the Cappuccino sites).
Objective-J is essentially a partial implementation of a Javascript-based Objective-C runtime. Technically, the implementation consists of a Javascript preprocessor, which, on the basis of regular expressions, turns Objective-J into regular Javascript. It also includes several functions (similar to Objective-C runtime) for accessing low-level language concepts. So there are functions for dynamically creating classes, a list of ivar, adding new selectors. In essence, the class implementation parser turns the description into the calls of these particular functions.
In addition to the preprocessor and the implementation of RTTI, the basic functions of the language include casting Javascript types into Cappuccino types (something like the βfree bundleβ of Carbon-Cocoa). So you can call selectors for strings or arrays:
The next component of Cappuccino is the Foundation. In essence, a copy of the Foundation from Cocoa, not counting the change of the prefix NS to the prefix CP. Mac programmers feel at home. Well, or almost at home - because the number of classes and the selectors implemented in them is significantly less. The biggest problem in the Foundation is now observed with the documentation, because people without Cocoa come to try Cappuccino, and they find the poorly described methods by which their code sometimes speaks much more than a documentary comment. The situation is complicated by the fact that the Objective-C parser from Doxygen is used to generate API documentation in Cappuccino, which in some places other than Objective-C syntax simply stops.
')
In the bugtracker there are several patches that extend the functionality of the Foundation, but they are not in a hurry to add them to the upstream. Perhaps because patch authors first need to sign the Contributor's License Agreement , in fact, a contract for the transfer of all rights to the code in 280 North. This is not a problem (if you write a patch to the framework - in most cases you donβt mind doing anything you like with it), but it scares away those programmers who donβt want to get involved in βpaper tinselβ also creates a queue of patches in the upstream.
The situation with AppKit is generally identical to the Foundation. User interface classes adapt to the realities of the Web, which somewhat modifies them in the process. There is a lack of CPTableView, whose counterpart in Cocoa performs all the tasks of implementing the interface of tables and lists. Key-Value Observing is absent, along with it is an analogue of Cocoa Bindings, thus data can be transferred only through delegates. Programmers who are not familiar with Cocoa find it difficult to understand the positioning model of the species (there is even a separate tutorial on this topic). In general, the layout of the interface takes a lot of time. The nib2cib converter of nib and xib files (interface descriptions from Interface Builder) in the native Cappuccino format is at the experimental stage. Of course, using IB to design the interface is easier and more familiar, but firstly, the result always has to be significantly improved by the file, and secondly, only OSX users have Interface Builder.
Recently the situation with Cappuccino is improving. Ordering in bugtracker is improved, documentation on basic language concepts is improved (for ordinary html / css / js web developers). Potentially - for Cappuccino are ample opportunities. Even now, making rich Internet applications on Cappuccino is in many cases easier than targeting js-tulkits (for example, Bindows).
Objective-J is essentially a partial implementation of a Javascript-based Objective-C runtime. Technically, the implementation consists of a Javascript preprocessor, which, on the basis of regular expressions, turns Objective-J into regular Javascript. It also includes several functions (similar to Objective-C runtime) for accessing low-level language concepts. So there are functions for dynamically creating classes, a list of ivar, adding new selectors. In essence, the class implementation parser turns the description into the calls of these particular functions.
In addition to the preprocessor and the implementation of RTTI, the basic functions of the language include casting Javascript types into Cappuccino types (something like the βfree bundleβ of Carbon-Cocoa). So you can call selectors for strings or arrays:
objj> ["test" length] four objj> [[1, 2, 3] objectAtIndex: 1] 2
The next component of Cappuccino is the Foundation. In essence, a copy of the Foundation from Cocoa, not counting the change of the prefix NS to the prefix CP. Mac programmers feel at home. Well, or almost at home - because the number of classes and the selectors implemented in them is significantly less. The biggest problem in the Foundation is now observed with the documentation, because people without Cocoa come to try Cappuccino, and they find the poorly described methods by which their code sometimes speaks much more than a documentary comment. The situation is complicated by the fact that the Objective-C parser from Doxygen is used to generate API documentation in Cappuccino, which in some places other than Objective-C syntax simply stops.
')
In the bugtracker there are several patches that extend the functionality of the Foundation, but they are not in a hurry to add them to the upstream. Perhaps because patch authors first need to sign the Contributor's License Agreement , in fact, a contract for the transfer of all rights to the code in 280 North. This is not a problem (if you write a patch to the framework - in most cases you donβt mind doing anything you like with it), but it scares away those programmers who donβt want to get involved in βpaper tinselβ also creates a queue of patches in the upstream.
The situation with AppKit is generally identical to the Foundation. User interface classes adapt to the realities of the Web, which somewhat modifies them in the process. There is a lack of CPTableView, whose counterpart in Cocoa performs all the tasks of implementing the interface of tables and lists. Key-Value Observing is absent, along with it is an analogue of Cocoa Bindings, thus data can be transferred only through delegates. Programmers who are not familiar with Cocoa find it difficult to understand the positioning model of the species (there is even a separate tutorial on this topic). In general, the layout of the interface takes a lot of time. The nib2cib converter of nib and xib files (interface descriptions from Interface Builder) in the native Cappuccino format is at the experimental stage. Of course, using IB to design the interface is easier and more familiar, but firstly, the result always has to be significantly improved by the file, and secondly, only OSX users have Interface Builder.
Recently the situation with Cappuccino is improving. Ordering in bugtracker is improved, documentation on basic language concepts is improved (for ordinary html / css / js web developers). Potentially - for Cappuccino are ample opportunities. Even now, making rich Internet applications on Cappuccino is in many cases easier than targeting js-tulkits (for example, Bindows).
Source: https://habr.com/ru/post/52098/
All Articles