Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!samalone
From: samalone@athena.mit.edu (Stuart A. Malone)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC segmentation
Summary: LSC & LSP need better segmentation
Keywords: LSC LSP segmentation
Message-ID: <8411@bloom-beacon.MIT.EDU>
Date: 12 Dec 88 17:10:31 GMT
References: <2791@uhccux.uhcc.hawaii.edu> <18118@agate.BERKELEY.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: samalone@athena.mit.edu (Stuart A. Malone)
Organization: Massachusetts Institute of Technology
Lines: 39

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