lippin@spam.berkeley.edu (The Apathist) (12/10/88)
Recently Rich Siegel was quoted by Mike Morton: > Source pros: Easiest to maintain; simply change it on the fly. > > Source cons: Has to be recompiled frequently if you do a Remove > Objects or something of that ilk. Is the slowes > way to load of these three options. My biggest source pro is segmentation. A library, like a source file, is only allowed to be in one segment. Perhaps my biggest gripe with LSC is the inability to do function level segmentation. File level segmentation is a problem, as I feel that files should be laid out along conceptual and data-sharing boundaries (which I like to think are related). On the other hand, segmentation should be based on similarity of call time, which can indicate a different arrangement. Contrarily, I consider MPW's compiler comments to be an inappropriate solution for LSC; it would be better to use something like the current drag-things-around interface. Since there are often too many functions in a project to make this practical on a global level, my suggestion is to allow a segmentation window to be opened for each file, and let the functions in that file be dragged around there. Libraries, or at least subprojects, could have their own internal segmentation, and their segments would be added to the main project's. In order to preserve some of the ease of use of the current system, there should be a simple default segmentation, say throwing everything but libraries into a single segment "main." Also, a method should be provided to move many functions at once; this could be as simple as a "select all" command used in the file segmentation windows. Comments, suggestions, implementations welcome. --Tom Lippincott lippin@math.berkeley.edu "I'm disappointed too, but keep in mind that transmogrification is a new technology." --Calvin
samalone@athena.mit.edu (Stuart A. Malone) (12/13/88)
In article <18118@agate.BERKELEY.EDU> lippin@math.berkeley.edu writes: >Perhaps my biggest gripe with LSC is the inability to do function >level segmentation. File level segmentation is a problem, as I feel >that files should be laid out along conceptual and data-sharing >boundaries (which I like to think are related). On the other hand, >segmentation should be based on similarity of call time, which can >indicate a different arrangement. Let's hear it for Tom! Having segmentation on a function-by-function basis would be a tremendous aid to writing large programs in LSC, and is even more important in LSP 2.0, which supports Object Pascal. When defining an object in Object Pascal, you want to put the implementation of each object in a separate file, but in LSP this means having initialization code, printing code, etc., spread all over the system. I have heard that the main reason that MacApp isn't available for LSP 2.0 yet is that THINK has had to reorganize it so that it segments properly. But reorganizing MacApp only solves the problem for this particular release of MacApp, not for future releases (which will have to be reworked again), or for customers of LSP (who will have to organize their code to suit the compiler). Doesn't it make far more sense for THINK to solve the problem once and for all by adding function-by-function segmentation to LSC and LSP? A simple segmentation system would be that each function *defaultly* falls in the segment that its file is in, but could be dragged to another segment using the mouse in a special window. New and renamed functions would land in the default segment until they were moved elsewhere. This remains compatible with the old system while providing the necessary functionality. I have a lot of respect for THINK, and will happily continue to use LSC as it is. But I have postponed buying LSP 2.0 until I see what THINK's commitment to MacApp is. I don't want to wait six months after each release of MacApp for THINK to resegment the code, and would prefer a version of LSP that doesn't force me to change my coding style to achieve good memory management. --Stuart A. Malone systems programmer, MIT samalone@athena.mit.edu