Linked by Thom Holwerda on Sun 4th Sep 2005 17:00 UTC, submitted by <a href=
OpenStep, GNUstep Objective Modula-2 (or ObjM2) is an extension to Modula-2 which follows the Objective-C object model and retains the bracketed Smalltalk message passing syntax introduced in Objective-C. Like Objective-C, Objective Modula-2 is a reflective, object oriented programming language with both static and dynamic typing. It is intended as a safer alternative to Objective-C for Cocoa and GNUstep software development.
Permalink for comment 27662
To read all comments associated with this story, please click here.
Why Oberon was ruled out
by Anonymous on Mon 5th Sep 2005 23:26 UTC in reply to "RE: give me a taco"
Anonymous
Member since:
---

There are two reasons why we chose Modula-2 and not Oberon.

First, the members of the core team are all Modula-2 veterans. Some have been part of the ISO Modula-2 working group and the leader of the GNU Modula-2 compiler project is also participating.

Secondly, it is wrong to assume that it is easier to add Cocoa support to a language simply because it was designed as an object oriented language. As a matter of fact, in most cases it is quite the opposite.

It is far easier to add Objective-C style language extensions to a non-OO language in order to support the Objective-C object model directly than it is to write and maintain a bridge to translate from one object model to another. Building bridges is a very troublesome business.

Check out the source code of some of the Cocoa bridges which are open sourced, eg. PyObjC. You will find there are plenty of "special cases" that need workarounds and "problem cases" the bridges cannot handle at all. Consequently, not all of Cocoa is covered by a bridge. Not even Apple's Java Bridge covers all of Cocoa.

You also have to take into account that Cocoa objects are dynamic, they can be dynamically typed and they are linked at runtime, not at compile time. None of the object models found in the Pascal family are dynamic. This makes it even more difficult to build a bridge.

What we wanted was to AVOID the need for a bridge altogether. We also acknowledge the merits of the Smalltalk derived message-passing syntax of Objective-C. Its expressiveness adds to clarity and maintainability of the code.

This meant that a language without any OO features would be preferable because we were going to add the Objective-C object model inclusive of its message-passing syntax to it.

Of course you could let the existing OO features coexist with the added Objective-C OO model, which is basically how Apple's Objective-C++ works, but this is not what we wanted to do.

BTW, ISO Modula-2 is an OO language and it has exception handling, termination, generics etc etc. In other words, ISO Modula-2 is to Modula-2 what C++ is to C.

Yet, we found that all those extras in ISO M2 are actually getting in the way. We don't want Cocoa support to be duct taped to whatever looks like it fits the duct tape. What we want is full Cocoa support embracing the Cocoa philosophy in its entirety.

Our specification is therefore predominantly targeted at Base Modula-2, which is to say M2 as defined by Wirth in PIM or ISO Modula-2 as defined by the base standard.

However, we are careful not to add syntax that would later make it impossible to use the ObjM2 extensions with the extended ISO Modula-2 standard. As GNU Modula-2 will gradually evolve to eventually support all three parts of the ISO M2 standard, there could well be a mode in which the compiler operates as an ObjM2++ compiler so to speak. However, this would be similar to Apple's Objective-C++ where there is no interchange between C++ objects and Objective-C objects. Likewise, without a bridge, there would be no interchange between ObjM2 (=ObjC) objects and ISO M2 OO objects.

Last but not least, Oberon is a poor choice in respect of the available target groups. First, we are not aware of any Oberon compiler that integrates with the GNU compiler collection (and thereby with Xcode), which is a significant disadvantage for acceptance by Cocoa developers. Second, for Pascal, Delphi, Modula-2, Modula-3 or Ada developers it is generally acceptable to use any of those languages, but Oberon is often not as it removed to many features they have come to appreciate. Likewise, for most Objective-C developers, Oberon would be difficult to swallow.

The feedback we are getting so far would seem to suggest that we made the right choice and that we are doing the right things in respect of those target groups, which includes Objective-C developers, some of whom have joined our project.

with regards from
the ObjM2 project

Reply Parent Score: 0