🚀 go-pugleaf

In article <2842A34C.983@deneva.sdd.trw.com> thomsen@spf.trw.com (Mark R. Thomsen) writes:
   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.

I don't believe that even the so-called "Common" classes that NeXT
distributes are StepStone.  The main reason that I don't think they
are is that there is quite a large gap in the general ideas behind
NeXT's Common classes and their StepStone counterparts (at least
this is the impression I get from the StepStone manuals).  For
instance, NeXT doesn't use the AsciiFiler stuff - though there
is similar functionality in the archiving methods, it's not done
in the same manner.  Also, the method names do not follow the
same conventions (for the List and Storage classes).  The NeXT
classes don't follow the same hierarchy - I would expect
List to be a subclass of Storage, like IdArray is a subclass
of Array in StepStone's stuff.

Then again, I might be full of it.  But I think that NeXT did
their own base classes, and probably the runtime stuff, too.

     ... 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, ...).

Somehow, I suspect it would not look as "elegant", which is a big
thing with NeXT . . . :-).

Later,
--
scott hess                      scott@gac.edu
Independent NeXT Developer	Graduated GAC Undergrad!
<I still speak for nobody>
Note:  I have moved home for a time.  My email address will still be
valid.  Any SnailMail should be redirected, along with phone calls.
At the least, my parents can tell you how to get hold of me, or
forward any mail . . .
Old:	PO 829, GAC, St. Peter, MN  56082	(507) 933-8466
New:	RR#4 Box 227 Pipestone, MN  56164	(507) 825-2788