Copyright ©1999 by AAA+ Software Forschungs- und Entwicklungs Ges.m.b.H.  All Rights Reserved.

5 Objective-C compatibility





This section demonstrates that you can execute your standard Objective-C code in Joy's interpreted environment. It shows that your users won't notice any performance hit as a result of your use of Joy. And most importantly, it shows you how you can save time on your everyday EOF and other development projects without writing any specific Joy code.

Where to find the example

The example can be found in the Examples directory. If you have not installed Joy yet, don't worry, just wait until you have. Otherwise, look in:

     /Local/Library/Joy/Examples/JoyStudios

(On a Windows computer, look under $NEXT_ROOT with the same path)

In this directory, there is a README file. Look at this file to see the simple steps that were taken in the preparation of this example.

Differences still remaining between Joy and Objective-C

Joy's original design goal was just to make a great scripting language for Objective-C. This has now changed, the goal is full compatibility. However, some features of Objective-C are not supported yet:
  • Certain macro definitions cause problems. Joy does not currently have a full textual preprocessor like C; and as a consequence there are some situations it cannot handle.
  • Occasionally, access to elements of structs by name is impossible. This is because the C runtime system does not record this information. Sometimes Joy can work it out, sometimes not. Until we solve this problem, the best solution is to use a typecast. For example, if [object method] returns a structure, just write (struct MyStruct) [object method] in your program. (This works fine in Objective-C as well)
  • There are slight syntactic inconsistencies for static initializations of structures and arrays. This is due to the fact that total compatibility initially was not a goal and the syntax present in JavaScript is actually superior.
  • There can be problems with forward references to structures from other structures. Again the best workaround is a type cast.
These caveats will be removed from future releases.

Conclusions

For a real project, using Joy from conception, it would be possible to keep the implementation simpler and more elegant. This example just demonstrates how compatible Joy is with standard Objective-C syntax and code. It is capable of parsing and interpreting a piece of standard Objective-C: one of Apple's examples no less.

As you will see from running this example, the user's perceived performance is no less than with the compiled version supplied by Apple. The bottleneck with such applications is the graphics system, the database engine, and the database communication. Consequently, the choice of language to express the application logic should be one of ease of use and simplicity, not of performance.

At AAA+ Joy is used for all development projects. Not only is the tedious compilation of large projects a thing of the past, but code can be tried out quickly and rapidly in Joy's flexible development environment. Large applications, written entirely with Joy, containing zero custom compiled code, are being deployed internationally.

The next section explains how you can use Joy to write a full application right inside InterfaceBuilder without any compiling or linking.