This is Structured-Code-browser-for-Objective-C-classes-..... in view mode; [Up]
Date: Sun 27-Sep-1989 18:02:15 From: Unknown Subject: Structured Code browser for Objective-C classes ..... A structured code browser that I have in mind is similar to the Smalltalk browser. For instance, when I invoke the class view within the IB, I am able to "see" a class hierarchy and the messages associated with each class. However, when I attempt to "get at the code" associated with a message (via a double-click on the message), nothing happens. In Smalltalk, when you select a message, the code is displayed and the programmer can modify the code there. I think it is a shame that ideas such as a structured code browser are not included within the NeXT environment. ParcPlace has a product for the C++ world which does include a structured code browser. Furthermore, I have heard that Stepstone does have a structured code browser for Objective-C. Where is it? And why wasn't it included in the IB? >From: rick@hanauma.stanford.edu (Richard Ottolini)
Date: Sun 27-Sep-1989 21:20:34 From: Unknown Subject: Re: Structured Code browser for Objective-C classes ..... In article <12146@boulder.Colorado.EDU> chase@boulder.Colorado.EDU (Stumpy) writes: >A structured code browser that I have in mind is similar to the Smalltalk >browser. For instance, when I invoke the class view within the IB, I am >able to "see" a class hierarchy and the messages associated with each class. >However, when I attempt to "get at the code" associated with a message >(via a double-click on the message), nothing happens. In Smalltalk, when >you select a message, the code is displayed and the programmer can modify the >code there. > >I think it is a shame that ideas such as a structured code browser are >not included within the NeXT environment. ParcPlace has a product for >the C++ world which does include a structured code browser. Furthermore, >I have heard that Stepstone does have a structured code browser for >Objective-C. Where is it? And why wasn't it included in the IB? > > Structured browsers are harder in C-based languages because they go through two steps of compilation where information MAY be discarded-- first C++/ObjectiveC into straight C where lot of the objectiveness is lost and C into executable where symbols names and structures may be eliminated. Smalltalk was originally interpretated and always kept its object organization around. These days the boundary between interpretation and compilation are less distinct. Smalltalk has a virtual-machine low level code and good C debuggers retain most of the original code information. UNIX/C is gradually acquiring many of the characteristics of the Smalltalk environment, first with objective C, second with NeXTStep, and third with NeXTStep applications. Straight Smalltalk had been painfully slow, even on Xerox machines, until the recent ParcPlace implementations on 10-MIPS+ workstations, so it was a curiosity rather than a platform in most labs. >From: bajan@OPUS.CS.MCGILL.CA (Alan Emtage)
Date: Sun 28-Sep-1989 17:45:28 From: Unknown Subject: Re: Structured Code browser for Objective-C classes ..... <<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 >From: phd_ivo@gsbacd.uchicago.edu
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.