Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!jans
From: jans@tekgvs.LABS.TEK.COM (Jan Steinman)
Newsgroups: comp.sys.next
Subject: Re: Structured Code browser for Objective-C classes .....
Message-ID: <6015@tekgvs.LABS.TEK.COM>
Date: 28 Sep 89 17:45:28 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 38
<>
<
There's nothing magic about how Smalltalk does it. Rick implies that
interpretation causes it to "keep object organization", which is somehow
responsible for good browsers. Because all of a given Smalltalk application is
kept in a single "image", symbolic names are always available -- perhaps this
is what Rick had in mind. Interpretation has nothing to do with it --
Smalltalk is compiled into an intermediate "virtual machine code", which
destroys the same sort of context Rick mentioned. (Try reading de-compiled
Smalltalk code!)
I submit that it is the archaic Unix object file format that is holding back
such things. On most such systems, you must explicitly strip(1) a file to be
rid of symbolic information, yet such information is largely inaccessible to
the the program itself! Any system that supports dynamic binding should have
these symbols "bound" to the appropriate methods (Smalltalk, Objective-C) or
virtual function pointers (C++). Code browsing and debugging will remain
tedious and slow as long as they are viewed as separate activities from
programming in general.
Smalltalk source code is kept in up to eight files, although two are typically
used, and there is no reason other implementations would be limited to eight.
The file index and offset into the file is kept with each method (virtual
function pointer). This enables even a 68000 based "slow" Smalltalk system to
browse and debug faster than a modern RISCy machine using traditional tools and
languages, object-oriented or not.
Jan Steinman - N7JDB
Electronic Systems Laboratory
Box 500, MS 50-370, Beaverton, OR 97077
(w)503/627-5881 (h)503/657-7703