graeme@cheviot.uucp (Graeme Dixon) (10/03/85)
Has anybody any experience of Objective-C from PPI? Does it live up to the promises made? Mail me and I'll summarise to the net. Objective-C is a trademoark of PPI. -- Graeme Dixon - Computing Laboratory, University of Newcastle upon Tyne, UK ARPA : graeme%cheviot.newcastle.ac.uk@ucl-cs.arpa JANET : graeme@uk.ac.newcastle.cheviot UUCP : <UK>!ukc!cheviot!graeme
riferguson@watmath.UUCP (Rob Ferguson [MFCF]) (10/09/85)
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