Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!umd5!cvl!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Structured design, goto's, and the holy grail
Message-ID: <10381@mimsy.UUCP>
Date: 29 Jan 88 14:49:09 GMT
References: <11528@brl-adm.ARPA> <23777@cca.CCA.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 38

In article <23777@cca.CCA.COM> g-rh@cca.CCA.COM (Richard Harter) writes:
>... There is a school that holds that inter-module communication
>via global data is undesirable (strong, unstructured coupling.)
>This school is wrong.

I would not quite put it that way.  I think the greatest problem
with global data can be summed up in a single word: encapsulation.

>	The problem with global data, the goto, the procedure that can
>be called from anywhere, et al, is that these are primitive constructs
>that do not have structure associated with them.

Exactly.  The structure must be imposed externally:

>The fundamental problem is lay out principles of structuring that
>can be used in general, and not merely in a restricted subclass of
>problems.

and one way to impose that structure is to reduce the number of
such constructs to something manageable.

>Modularization is often cited as an important programming principle,
>and it is.  But what it really does is push the problem up the scale.
>When you have hundreds or thousands of modules, you have the same kinds
>of problems as when you have hundreds or thousands of statement numbers.

Sure.  Then the problem becomes one of heirarchically making clusters
of modules, with rules for interaction between clusters, and so
forth.  I think both Ada and Modula-2 have problems here; indeed,
I know of no language that provides a really decent solution.
(Look at the problems people have building pipelines on Unix
machines, for instance.  If each utility is considered a module,
we have hundreds of modules available.  Since a utility that
consists of a pipeline is simply another utility, what we did by
making one was to make the module space bigger!)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris