Objective-C??

Rob Ferguson [MFCF] riferguson at watmath.UUCP
Thu Oct 10 04:15:08 AEST 1985


About a year ago, I was part of a research team which evaluated Objective-C 
as part of a project investigating software development tools for large
applications. I wrote a report on Objective-C and its potential usefulness
which I can probably exhume if anyone is that interested, but I'll summarize
the basic conclusions (as I remember them) here.


[Disclaimer: it's been over a year since I looked at this, and even then
my experience was much more limited than I would have liked. This is also
discussing Objective-C as it was at that time; I have no idea if the product 
has been improved or changed in the interval...]

[Disclaimer #2: I'm going to assume that the reader understands the basics
of object-oriented programming; it'd be too long to explain all that here...]

_________________


Objective-C is a pre-processor for the C language which claims to allow
object-oriented programming (a la Smalltalk) in a more traditional
environment than is normally associated with object-oriented systems.
The basic claim of PPI is that Objective-C provides the efficiency of
traditional programming languages coupled with the ease of use and
development associated with the object-oriented paradigm (e.g.
polymorphic code and inheritance, data abstraction, etc.).

Well, as with all sweeping claims like that, it's both true and false. 
First, the good points:

	- Objective-C works. You really can produce working C programs
	  which have "message passes" embedded in them. The inheritance
	  mechanism works, too.

	- It is easy (syntactically) to switch from writing normal C code
	  to writing code which (conceptually, at least) passes messages
	  to objects.

	- The mechanism for compiling an Objective-C program is identical
	  to that of compiling a regular C program (you type "objcc" as
	  opposed to "cc"). What actually happens is that the Objective-C
	  compiler is invoked, which produces a  "normal" .c file; this 
	  second file is then fed into 'cc'. The compile times are not
	  slower by any appreciable amount than those which would be
	  produced by feeding a normal C file of the same size to 'cc'.

	- My dealings with the company itself were great. Prompt service 
	  and replies to technical questions -- they seemed to be genuinely 
	  interested in how things were going. 


There are lots of bad points, however:

	- the integration between "normal" C and Objective-C is poor.
	  If you have an "string" object (i.e. something which you
	  could use as the receiver of messages recognized by the
	  "String" class), you have to explicitly convert it into a
	  "normal" C string before you can use it for anything like
	  strlen.  I suppose this is a reasonably obvious fallout of
	  having both types of programming paradigm available, but when
	  you are writing code, the mental context switches are very
	  annoying ("Is str an object-string or a string-string?").

	- the supplied class library is trash - poorly designed and
	  poorly implemented. The interfaces conform to selected parts
	  of the Blue Book ["Smalltalk-80, The Language and its
	  Implementation"], but the implementations differ greatly and
	  are generally much poorer.  We threw the library away, except
	  for the most basic things like the "Object" class (which we didn't
	  dare to rewrite). To PPI's credit, at least they supplied us
	  with the Objective-C source to all the class libraries.

	- Objective-C doesn't come with any sort of browser or other
	  online interface to the class library. You don't realize what
	  you are missing until you use Smalltalk for a while...

	- when writing an Objective-C program, the user must declare
	  not only the classes which he references in the program
	  (not unreasonable) but also all classes which are referenced
	  by the classes which he references, and so on (very unreasonable).
	  In other words, the programmer must know how all the classes 
	  which he references are implemented (!). This sort of nullifies
	  the claims of data abstraction that PPI makes.
	  [ Note: I recall PPI saying they were going to fix this. I don't
	    know if they have or not. ]

	- there is no source level debugging facility for Objective-C
	  programs. One can use the "normal" C files which are produced
	  by the Objective-C compiler for debugging, but they're cryptic,
	  to say the least.

	- The syntax of the object-oriented parts of Objective-C is one 
	  of the most aesthically unpleasing things I have ever seen.

	- The actual implementation of message passes involve a call to 
	  a routine called _message, which is an assembler hack. Objective-C
	  must therefore be specifically tuned to the machine and C compiler
	  that you are going to use it with.


My only fundamental problem with Objective-C, though, had to do with the
lack of compatablility between the two different ways of programming:
Algol-style vs. Smalltalk-style. It can be very awkward switching contexts
continually -- and you must, in order to interface with the Unix system
calls (for example). I think all the other problems that I've mentioned can 
either be easily solved or aren't all that important; the compatability
problem is intrinsic to the entire idea of Objective-C, however.


----------------

Hope this answers some of the recent questions about Objective-C and PPI. 


Cheers,

rif

.......................

Rob Ferguson 	{allegra,clyde,decvax,ihnp4,linus,utzoo}!watmath!riferguson 



More information about the Comp.lang.c mailing list