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

<<chase@boulder.Colorado.EDU (Stumpy)>>
<<A structured code browser that I have in mind is similar to the Smalltalk 
browser...  In Smalltalk, when you select a message, the code is displayed and 
the programmer can modify the code there.>

<rick@hanauma.stanford.edu (Richard Ottolini)>
<Structured browsers are harder in C-based languages...  Smalltalk was 
originally interpretated and always kept its object organization around...>

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