Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!spam!lippin
From: lippin@spam.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: LSC segmentation
Message-ID: <18118@agate.BERKELEY.EDU>
Date: 10 Dec 88 05:50:50 GMT
References: <2791@uhccux.uhcc.hawaii.edu>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 40

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