Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!usc!aero-c!gumby.dsd.trw.com!deneva!news
From: thomsen@spf.trw.com (Mark R. Thomsen)
Newsgroups: comp.lang.objective-c
Subject: Re: Health of Stepstone and ObjC
Message-ID: <2842A34C.983@deneva.sdd.trw.com>
Date: 28 May 91 18:36:59 GMT
References: <PETRILLI.91May23225456@geech.gnu.ai.mit.edu>
Sender: news@deneva.sdd.trw.com
Organization: TRW Inc., Redondo Beach, CA
Lines: 65

Chris Petrilli writes

  I really should clarify this... In my discussions with NeXT, which
  concerned Objective-C in GNU C, I was told that the object libraries,
  in general, belong to StepStone (appologies to NeXT if this is
  incorrect interpretation), as I was told that the FSF would have to
  recreate them since NeXT didn't own them.

I would guess the Object class is an example of an intrinsic class for
Objective-C that is in the object library. NeXT refers to this as a
common class. Others are HashTable, List, NXStringTable, Storage, and
StreamTable. Obviously NX___ is a NeXT item. All others have at least
a NeXT feature (e.g., archiving) added. To maintain compatibility with
OC specifications, the methods would have to be a superset (or a
subclass, though this does not appear to be how it was done). It is
noteable that 'StepStone' does not appear anywhere in the NeXT documen-
tation (V2.0) except under suggested reading - not even as a trademark.
  
  As for C++ becomming the 'default' language for NeXTs, don't hold your
  breath.  For reasons that are more complex, C++ is technically
  incapable of supporting the NeXT fully.  The machine is designed for
  the message passing architecture of Objective-C (which is similar to
  Flavors under LMI Lisp).  After discussing C++ vs. Objective-C with
  people, I think NeXT supports it grudgingly, and I know the
  programmers at NeXT despise it, as do I.

I am told that Objective-C was selected when it was selected because the
dynamic binding was real and C++ was just getting out of the gate. We
started a project here with a desire for OOP on a Sun in 1986. Since
neither OC nor C++ were ready for prime time we devised ClassIC (classes
in C), modeled after OC as described in the old Cox book. Added mixins,
class variables, and a few other Smalltalk features. Worked well but
has since been getting killed. OC seemed to have the right light
syntactic features. We built something like NeXTstep without the
Interface Builder. Of course, when NeXT announced their product we
were most interested and well prepared.

C++ is sort of a reality issue - not supporting C++ would be a
religious issue. I sense a widening arena of C++ software development
and while I agree wholeheartedly with your OC vs. C++ assessment, the
tide of history seems to favor C++. Allowing users to port and write
C++ code and using OC as an internal development capability gives
NeXT and us a good, balanced position. For now I will continue to
listen to my developers and support OC development - I don't feel
OC would die with StepStone.

  ... NextStep and Interface Builder cannot exist (in
  anything resembling their current state) under C++.

I would hazzard that NeXTstep could be built (same functions,
similar interface, etc.) with C++. Oh, NeXT might have to add and
play with it some (more than with OC?), but they would get there.
(This is not hard for me to imagine since we added the stuff to
C to make ClassIC - create the dynamic glue and map appropriate
procedure calls and variables into the message/name table within
the glue parts, ...).

However productivity might suffer and the programmers would not be
pleased.

Oh, and I don't want this construed as a C++/OC comparison on
technical merits. The original, underlying issue remains in the
subject line, with NeXT and NeXTstep as the subtopic.

Mark R. Thomsen