Objective-C / Java / Groovy

Posted: September 3, 2008 in IT/Dev
Tags:

Here a some major advantages of Objective-C (language used to build Cocoa and WebObjects) over Java :
Java does not comply with the message concept, as it directly binds the message concept to a method call on an object (that must be known). However the message (command) should be dissociated with the method call (result of the command sent).

The Objective-C runtime natively includes a messaging/delegation system (Responder Chain, delegates objects chain), and the target of a message (that can respond to it) isn’t known (and hasn’t to be) by advance. Cocoa frameworks (AppKit, etc.) use delegate objects definition (bind through InterfaceBuilder for example) in order to redefine/extend objects behaviours without the need to subclassing. With Java nothing has been planned to deal with that. The target object must be known (or at least its interface, even with reflection APIs, except when the class name is specified in a configuration file and in the client code – as with the O/R mapping layers) by advance. Set up a messaging bus (as the Responder Chain) would lead to a less than elegant syntax. 

The Objective-C selector feature is more elegant than Java reflection APIs, and we can instantely (and easily) check if an object can respond to a message (without having to know its type). Classes also can be extended at runtime (or be swapped/replaced), and a native proxy aspect is present. br>
And what about Groovy : it brings nothing new compared with Objective-C, and despite its compatibility with Java JVMs, it requires an aditionnal compilation step (that hits the programming flow).

Advertisements
Comments
  1. Will Rogers says:

    I have been learning Groovy and Objective-C, and have some limited perspective on this. I would like to see Apple do for Objective-C what Groovy did for Java. In fact, I would love to see Apple adopt the Groovy language specification and perhaps contribute to its evolution and produce a ‘CocoaScript’ language that adhers to the Groovy spec but compiles to native code “C” code and interfaces with Objective-C. This would produce one language that would be implemented as Groovy for Java and CocoaScript for Objective-C that would share the same, or extremely similar syntax and appeal to a wider audience than Objective-C does. Furthermore, it would be nice to see this CocoaScript replace or augment AppleScript on MacOS X. It would also be nice to have the same language supported on JavaScript and baked into WebKit, call it “WebScript”. In short, one language spec could be implemented across the JVM, Cocoa Frameworks, and WebKit. while the libraries available in each environment would be different, the language would be the same and be treated as a “First Class” language in each environment. Furthermore, standardized libraries for basic Date/Time, File, etc. could be made available on each platform, making alot of code cut and paste between runtimes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s