From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8bb81cae35ee307f
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Package Parts [was: Ada GC and a bunch of other stuff]
Date: 1996/02/23
Message-ID: <Dn8pKA.GM5@world.std.com>#1/1
X-Deja-AN: 140836812
references: <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com>
 <4gh2da$ffb@dayuc.dayton.saic.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-02-23T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <4gh2da$ffb@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>For that matter, if we accept this notion of declaring the part-names in
>a prior configuration package, then there's no particular reason why
>the part names need to be named numbers.  I have suggested that the
>part-names could be "enumerated" somehow.

You're getting closer and closer to child packages.  It seems to me that
if you want to think about this, you should start out with child
packages, and enumerate the things they can't do, or can't do well
enough for your taste (such as the mutually recursive types thing), and
think about how to modify the semantics of child packages to fix those
problems.  Inventing a whole new feature seems like overkill.

- Bob