From owner-sc22wg5@dkuug.dk  Wed Jun 25 21:06:57 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.12.8p1/8.9.2) id h5PJ6vjF061098
	for sc22wg5-domo; Wed, 25 Jun 2003 21:06:57 +0200 (CEST)
	(envelope-from owner-sc22wg5@dkuug.dk)
X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f
Received: from math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57])
	by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5PJ6pEc061093
	for <sc22wg5@dkuug.dk>; Wed, 25 Jun 2003 21:06:53 +0200 (CEST)
	(envelope-from vsnyder@math.jpl.nasa.gov)
Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1])
	by math.jpl.nasa.gov (8.12.8/8.12.8) with ESMTP id h5PJ6lJe030138;
	Wed, 25 Jun 2003 12:06:47 -0700
Received: from math.jpl.nasa.gov (vsnyder@localhost)
	by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h5PJ6lPG030134;
	Wed, 25 Jun 2003 12:06:47 -0700
Message-Id: <200306251906.h5PJ6lPG030134@math.jpl.nasa.gov>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: sc22wg5@dkuug.dk
Cc: longb@cray.com
Reply-to: Van.Snyder@jpl.nasa.gov
Subject: Re: (SC22WG5.2818) Directions for Modules TR - levels 
In-Reply-To: Your message of "Wed, 25 Jun 2003 13:58:15 CDT."
             <200306251851.h5PIpiHM061009@dkuug.dk> 
From: Van.Snyder@jpl.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 25 Jun 2003 12:06:47 -0700
Sender: owner-sc22wg5@dkuug.dk
Precedence: bulk


I wrote:

> >For a large module there may be a need to share entities between
> >procedures in different submodules.  With only two levels, the only place
> >to put those shared entities is in the module.  This is really part of
> >the implementation.  Putting it into the module could cause a
> >compilation/certification cascade as a consequence of changing an
> >implementation detail.  So you need at least three levels. Once you have
> >three, there's really no point to a limit, although I doubt in practice
> >we would see more than three.

and Bill Long replied:

> I had thought about the issue of sharing things among a group of 
> submodules. This seems like something that would be desirable.  However, 
> I don't agree that the only way to do this is with another layer of 
> submodules.  The shared stuff can be put in an ordinary module (not the 
> parent) that is used by all the submodules in the group.  This would 
> seem to me the natural thing to do, having used modules in this way for 
> a long time.  The module with the shared stuff is not a submodule, 
> eliminating the need for a third level, and is also unrelated to the 
> parent module, so does not affect the key feature of avoiding 
> compilation cascades.  Is there a flaw in this approach?  If not, it 
> seems that the simplification that results from just two levels is 
> desirable.

It doesn't work if any of the shared stuff depends on private stuff.

I'm in Richard's camp on this issue.  If we can't think of a really
compelling reason for an artificial restriction, we ought not to have it.
Searching for a reason not to impose an artificial restriction is not
the way I would develop things.


-- 
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder@jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or disapproved
by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.