Pike wrappers for ObjC classes are not generated in advance; they are created as they are requested based on reflection. Most methods will have a useful auto-generated Pike equivalent; additional methods, or hand written methods for which an auto-generated method wrapper would not be useful (such as those that return character pointers, like [NSString UTF8String], can be supplied as needed. These mixins are located in the mixins directory, with a mixin file for each class, using a slightly modified CMOD syntax.

The mixins are parsed at build time and a registration function is added to the module startup code, which populates a mixin table so that when a wrapper for a particular ObjC class is requested, the hand coded implementations and mixins can be inserted into the class definition.

Pike does not currently provide class-level methods, which are supported in ObjC. However, an implementation oddity in Pike allows function constants to be added to classes, and these seem to behave in a similar enough fashion for our purposes.

The main module contains initialization code to create an autorelease pool handler, generate the mixin list, the class cache and lookup mappings and prepare the Cocoa runtime for use in multi-threaded mode. Additionally, the main module included a number of utility functions for performing important tasks, such as inserting callbacks to the Pike backend loop in the Cocoa NSRunLoop (for use in GUI applications where the AppKit expects to have the backend) and vice-versa (for use in console or applications where most of the action is happening in the Pike backend, but for which you might wish to have access to Cocoa networking functionality, for example.) Methods exist for loading bundles, which allows Cocoa frameworks not originally present during build time to be made available for use by Pike applications (such as the popular Growl notification framework). Note that in this situation, custom coded mixins probably won't be availble unless they were specifically added to the module at build time (mixins don't necessarily need to have a given class available during compile time, but that's not a standard behavior).

The module also includes a Pike language component. There are a few support methods that are present that would have been difficult to implement in C, such as some type parsing functions. Additionally, the Pike language code provides a convenient technique for accessing objective C class wrappers: an object in the module provides an overridden index operator that makes calls to the lower level class generator so that code can be written as:

  object x = ObjectiveC.Cocoa.NSNumber();

instead of

  object x = ObjectiveC.get_dynamic_class("NSNumber")();

this convenience framework makes it also possible to use class names as types, which wouldn't otherwise be possible.

Calling Objective-C Methods from Pike

Passing Pike objects to Objective C

Accessing Pike classes in Objective C

Issues

- Parsing pike type signatures and converting to Objective C signatures

• Distributed Objects
• Passing Pointers
• Subclassing Objective C classes in Pike

  if objective-c code executes in a class that has pike components, will the pike code be called when necessary (ie, if a class overrides method x in pike, and some objective-c code in that class calls method x, will it call the pike method x, or the native objective-c method x?). right now, it's the latter, which is incorrect. Probable solution is to generate c-level IMP (method implementations) for each method written in pike and write them into the objective-c class's method table. This has implications for classes that make use of operator overloading to create fancy behavior.

  - Subclassing Pike classes in Objective C

  problem of efficiency: right now, we're using an NSProxy-like approach. Should we create libffi based stubs for calling each pike method and write them into a class's IMP (method implementation) table?

Powered by PikeWiki2