ObjectiveCee

Last edit June 3, 2014
Real name Objective-C. It is an object oriented extension to the CeeLanguage created at a time when CeePlusPlus was virtually unknown. It is basically C with blocks of SmalltalkLanguage in it (but no automatic GarbageCollection or blocks in ObjectiveCee 1.0, but these features have been added by Apple in the 2.0 release of Objective-C and iOS 4 respectively).

Maaster!! You have created ... a monster!!

Yes, Igor! By tr-r-ransplanting Smalltalk's virtual dispatch system into zee skull of my cadaver of zee C language, zee virtual messages shall move zee arms and zee legs of structs and ints! Und zey vill doo our biddings!! Vee vill rool zee wooorld!! Mwha-ha-haha!

Vhat vill you call heem, Maaster??

I vill call him... Id.

Very early implementations earned a reputation for slowness, and initially the only implementations were by BradCox.

SteveJobs and NeXt used Objective-C for a computer based on a Mach kernel, 680x0 processor, and Unix, with lessons learned from MacApp/MacOs, and Smalltalk. It was literally 10 years ahead of its time. [Time has since caught up with it.] Time hasn't entirely caught up. There are still OSs that are as pervasively object oriented (BeOs probably is one) and are as easy to develop for (BeOS is fun to program on, but it still doesn't come close to the old tools from that project). [NextStep is the OS discussed above.]

The JavaLanguage has a run-time model similar to Objective-C (and inspired by Objective-C, according to the creator of Java), but with syntax more like CeePlusPlus. BradCox has a record of this at http://virtualschool.edu/objectivec/influenceOnJava.html

I thought it was something about message dispatch being more like SmalltalkLanguage than C++.

WayneRosing, JamesGosling, and BillJoy wanted an environment "with the semantics of Smalltalk and the appearance of C". The desire was for "programmer portability"; the perception was (rightly or wrongly) that the infix syntax of Smalltalk was a major impediment to its acceptance by the development community. Smalltalk behavior was always the goal; CeePlusPlus and ObjectiveCee were thus viewed as relatively interchangeable options. -- TomStambaugh

Next, Inc. took the Objective-C portions of the gnu C compiler (and developed their own run-time library) and polished it over the next 10 years until runtime speed was comparable to (or better than?) modern Smalltalks. They didn't ship the source code to the compiler with Nextstep 10 years ago, but it available on request (on magtapes).

I think it's now available in Apple's Darwin project: http://developer.apple.com/darwin/

RichardStallman mentions a disagreement with Next over the philosophy of copyleft at http://www.gnu.org/philosophy/pragmatic.html

See BradCox' book "ObjectOrientedProgrammingAnEvolutionaryApproach"

That book defines Objective-C.

Another book: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf

in HTML: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html

[ links updated -- TheerasakPhotha ]

Objective-C has two tools, HeaderDoc and AutoDoc, that are similar to DoxyGen and JavaDoc. HeaderDoc ships with ExCode on Panther (MacOsx 10.3)
Objective-C FAQ: ftp://rtfm.mit.edu/pub/faqs/computer-lang/Objective-C/faq
Objective-C tutorial: http://otierney.net/objective-c.html
Does anyone know of an ObjectiveCee tutorial that doesn't assume knowledge of C? The apple documentation above reminds me of the Steve Martin bit "How to get a Million Dollars and Never pay Taxes": "First, Get a Million Dollars".

I don't know of one offhand, and since it's not one of the most popular languages in the world, you won't see a bunch of "Learn Objective-C in 20 Minutes For Dummies" books.

However, it is a superset of C, so there isn't a pressing need for such a combination. You can buy any number of C books to learn that part of the language, and then learn the Objective-C extensions to the language, which are very small in number and can literally be learned in an afternoon or less (although, as always, it takes longer to learn effective use of the class library).

The only feature that is actually a change, rather than an addition, is that include files should be imported via #import (which automatically enforces an only-once rule, sidestepping the ugly C hack for doing that). But even there, #include still works, so it's still backward compatible. ObjectiveCee is, in fact, a strict superset of CeeLanguage, meaning if you hand a CeeLanguage source to an ObjectiveCee compiler, it will compile it perfectly.

I was warned by using #import in gcc compiler. Should I use #include instead? 
 $ gcc -o hello hello.m -lobjc
 hello.m:1:2: warning: #import is obsolete, use an #ifndef wrapper in the header file
With the gnu compiler you should use "-Wno-import", in order to not get the warning... If you want one good book to learn Obj-C, buy "Programming in Objective-C", by Stephen Kochan.

See also: SteveJobs, NeXt, ObjectiveCeePlusPlus
[From ObjectiveCeeLanguage]

Extends the syntax of CeeLanguage to include Smalltalk constructs. An object-oriented C created by BradCox. The object-oriented extensions of ObjectiveCee rely on dynamic pointer-based mechanisms, as opposed to CeePlusPlus, which gains its behavior through more pervasive modifications of both the syntax and symantics of CeeLanguage. Many consider ObjectiveCee to be "more OO" than CeePlusPlus because of the Smalltalk heritage of ObjectiveCee. NeXTStep used Obj-C, and so does Apple now- the CocoaFramework is a port of NeXTStep's APIs.(of course, they're modified in MacOsx, but... the roots are the same). The GnuStep project is also porting the OpenStep frameworks to various OSes(*nix, Windows, etc.). Their website is http://www.gnustep.org. [original paragraph reworded to improve historical accuracy -- TomStambaugh]

With Objective-C, one gets the low-level capabilities of C as well as the high-level, abstract object-orientedness of Smalltalk. It's far from a compromise, however - the two languages fill in each other's gaps nicely. Objective-C only adds one major syntactical construct - the message send. 

	[receiver message];
Classes are added as well. These are declared as follows: 

 @interface SomeClass : ItsSuperClass
@interface is a preprocessor directive that tells the preprocessor, "a class is being declared. what follows are its instance variables and methods."

@interface seems not to be a preprocessor directive. cpp does nothing on it. [Objective-C was originally implemented as a preprocessor that converted the code to straight C. This is different from the traditional C preprocessor which understands things like #define. Modern Objective-C compilers are true compilers, and you probably couldn't implement the language with a preprocessor anymore.] 

 { // begin declaring instance variables
	int fooInt;
	id anObject;  // id is ' a pointer to an object.' it's a generic type-- any object can be typed as id.
 } //end declaring instance variables


 +(SomeClass *)objectWithFooInt:(int) theInt;
Plus '+' signifies class method. colon ':' signifies an argument. (int) types the argument, and theInt is what the argument is named. a 'method' is a set of instructions, something an object (in this case the class object) knows how to do. This returns an initialized, allocated, and autoreleased instance of SomeClass with a fooInt value of theInt. in order for it to stick around for long, the coder must tell it to do so by sending it a retain message: [theObject retain]; (retain is a method of NSObject that is involved with memory management and paired with a release method.) 

 -(id) initWithFooInt:(int) theInt object:(id) theObject;
This is an instance method which is roughly analogous to a constructor; the message is sent to an allocated instance, and the init method sets instance variables fooInt and anObject to theInt and theObject, respectively. it returns a fully initialized instance of SomeClass. 
 @end  //end of interface


 @implementation SomeClass
In here, the instructions are laid out, and the methods are coded like C functions. the exception is, they can call the superclass' implementation of the method. polymorphism is fully supported in Objective-C. 
 @end
-- JoeOsborn [but with modifications by TomStambaugh]

Attempts to add many missing Smalltalk features, such as blocks, are underway. See BlocksInObjectiveCee.
[From ObjectiveClanguage]

An ObjectOrientedProgrammingLanguage which combined the dynamic ObjectOriented features of the SmalltalkLanguage with the speed and low-level programming constructs of CeeLanguage.

CeeLanguage and CeePlusPlus were developed by BellLabs/AT&T, and ObjectiveCee was developed by Stepstone. With relatively high license fees, ObjectiveCee never saw broad use. Its major adopter was NeXT, which based the entire application layer of its OS (NextStep) on ObjectiveCee. ObjectiveCee lives on in the same role within MacOsx.

CeePlusPlus was made freely available by AT&T as a marketing ploy. It was never in the public domain. UNIX(tm) was quite intentionally a trademark of AT&T and has never been in the public domain. AT&T divested a portion of its resources, including UNIX, to NCR corporation for a short period. Meanwhile, a competing version of UNIX was created at CalBerkeley (by BillJoy, among others). For many years, the UNIX world was divided between "UNIX System V" (from AT&T/NCR) and "BSD UNIX", from Berkeley. Since AT&T offered CeePlusPlus for free, ObjectiveCee would have been "expensive" at any price. -- TomStambaugh

One of the quirkier things about ObjectiveC is its (Smalltalk-esque) syntax. Rather than using C++ (and Java's) dot notation for invoking methods, ObjectiveC uses a square bracket form (this is because a dot signifies membership/ownership - you can send any message to any object in Objective C, so a dot would inevitably be semantically wrong): 

	result = [objectInstance methodName:param];
and 

	result = [objectInstance anotherMethod:param1 with:param2 andWithAnotherParameter:param3];
Another hold-over from its lineage, though this one on the CeeLanguage side, was the use header files (for better or worse). However, at least one thing was fixed: header files are included via the "#import" directive, which automatically ensures that that file is included exactly once, obviating the conventional kludge in C/C++ to achieve that effect.

In practice, both of these are minor compared to the advantages of the language. The core concept that differentiates ObjectiveCee from most other compiled languages is its runtime. (The advent of CsharpLanguage has started to bring the power of this concept more to the fore.) To put it simply, in ObjectiveCee reflection is the way everything's done. There's no such thing as compile-time binding. In other words, ObjectiveCee is like an interpreted language in terms of flexibility and power (string-to-method-invocation is a no brainer) while having the speed of a fully compiled language (rather than being compiled only to byte code). (Yes, other O-O languages have some the data portion of a runtime: RTTI (RunTimeTypeInformation) for C++, and reflection accesses this information in Java, but no other compiled, C-based language uses the runtime for all method dispatch.)

A more significant limitation of Objective-C is its lack of namespaces and the issue of name collision. As a result various 2 and 3 letter prefixes on class names are common.

This power is achieved by encoding class information into the object files (in the sense of .o files, aka .dll or .so, also known as "libraries") as strings. Upon application execution this information is loaded into the "runtime": a collection of C data structs and functions that are linked into every ObjectiveCee executable. When a method is invoked, the instance's isa pointer is de-referenced to access the related runtime structs. The method is looked up BY NAME, first in the class and then in each superclass in order. Once a successful lookup has occurred (or failed to occur) the associated function pointer (or pointer to the error function) is cached so that future invocations are fast (~ 2-3x a simple function call).

ObjectiveC is a hybrid language. Within its O-O side it implements all the features of a dynamic O-O language. It supports single-parent inheritance. The base class of all objects is Object. (Actually the runtime supports multiple-base classes and in NextStep, the base class was NSObject,... details.) Having a runtime means that "new" (and generally computationally expensive) features of other languages (like "dynamic proxy classes in Java) are built-in.

From 1988-1995, the base class for the NextStep AppKit was Object. It had no reference counting; only +alloc, -init, and -free were implemented. NSObject was introduced with the Foundation Kit in NextStep 3.3, but only as part of the optional Enterprise Objects Framework. Thus, -retain and -release were introduced because of EOF's need for reference counting. Eventually, the OpenStep specification was written with NSObject as the base class, and the AppKit was rewritten massively to build on the new base class. [BrianWilloughby]

An interesting (and powerful) feature is that each Class is also (a special type of) Object in the runtime. Class methods ain't "static" -- they are just as dynamic as any instance method.

One of the slicker features of Objective-C was the notion of a "category". A category (analogous to an "extension" in Envy/IBM Smalltalk) is any collection of methods (class or instance) that are grouped together and given a a name. In addition to being a useful way of grouping class functionality so that multiple developers could conveniently work on different parts of a class, it allows for the addition of new functionality at any point in the class hierarchy by object consumers (rather than just producers). Say you need every instance of any subclass of the SuperGizmoWidget class that you purchased/found in some code library to be able to perform a "twirlAboutAxis:" method. Well, just add such a method into a category on the SuperGizmoWidget class and voila! In other words its the exact opposite of the notion of a "finalize"d class. The limitation is that since instance VARIABLES, unlike instance and class METHODS affect the amount of space that's allocated for an instance, you can't add variables in a category -- or new instances would become incompatible with existing compiled ones. ''

There are a few tricks to categories. Since the runtime must load the base class definition first, categories get loaded second. Conversely method lookups happen in the reverse order: whatever is loaded last is found first. So.... you can effectively override and replace any method on an class by writing a category method of the same name. This, of course, is generally not advised: though it does provide for a wickedly powerful tool for those terrible times when there are bugs in some otherwise very useful base class and you just wish you could fix the one broken method ... with ObjectiveCee, you can. [As the IBM Smalltalk community discovered, this can lead to pernicious bugs when multiple extensions/categories attempt to define the same method.]

Another feature of the language was its DynamicTyping. There has been much discussion over the years as to the desireability of this trait. One of the strongest arguments against dynamic typing was that it decreased the ability to do compile-time checks. Compile-time typing was later added to the language -- but it doesn't affect the runtime. In a way the type specifications in ObjectiveCee amount to code annotations that are parsed by the compiler and produce warnings (or errors) when there's a type mis-match or when trying to invoke a method that the compiler hasn't been informed of.

More information is at: http://www.dekorte.com/Objective-C/

The original ObjectiveCee compiler was a CeeLanguage pre-processor. That was back in the 80s. The current ObjectiveCee compiler has come a ways since then. It is now (thanks to previous negotiations with NeXT) part of the GnuCompilerCollection. The runtime has been enhanced to support multi-threading.

Various notable Applications have been written in ObjectiveC: EzraEpstein [with modifications by TomStambaugh] [Historical note by BrianWilloughby]

What do you mean by "no code and no code gen"?

Interface builder does actually generate code (but you have to force that to occur, and it only generates method stubs). However, wiring together the application via IB does not generate source code per se, it generates object instances and serializes them.
There is also an implementation in Clang (CeeLanguageFamilyFrontEnd).
At WWDC 2014, Apple replaced Objective C with SwiftLanguage
CategoryProgrammingLanguage CategoryCee CategorySmalltalk