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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5c89acd494ea9116 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Self pointer in limited record From: Georg Bauhaus In-Reply-To: <9cdmw7k85sey.85sb2t1bjefy$.dlg@40tude.net> References: <1183577468.034566.57830@n60g2000hse.googlegroups.com> <1188578849.187422.280620@50g2000hsm.googlegroups.com> <9fy1xoukz1e3$.h574sqmiauri$.dlg@40tude.net> <46d968ee$0$30368$9b4e6d93@newsspool4.arcor-online.net> <137iu0lr82dtb$.wqy3zjz2vr9q.dlg@40tude.net> <46d972e8$0$30384$9b4e6d93@newsspool4.arcor-online.net> <1alyfwaig93sk$.99oy269uon$.dlg@40tude.net> <46d9c138$0$4531$9b4e6d93@newsspool3.arcor-online.net> <1rt8kdcrj6tf.1qgvycc6vh357$.dlg@40tude.net> <46db2bf4$0$7699$9b4e6d93@newsspool2.arcor-online.net> <1188816674.2630.25.camel@kartoffel.vocalweb.de> <9cdmw7k85sey.85sb2t1bjefy$.dlg@40tude.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-ID: <1188851929.2630.85.camel@kartoffel.vocalweb.de> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Date: Mon, 03 Sep 2007 22:38:49 +0200 Organization: Arcor NNTP-Posting-Date: 03 Sep 2007 22:38:16 CEST NNTP-Posting-Host: f2c9acb0.newsspool4.arcor-online.net X-Trace: DXC=AfMBmlG1LC8gP]QSEBQ^d44IUK On Mon, 2007-09-03 at 16:17 +0200, Dmitry A. Kazakov wrote: > On Mon, 03 Sep 2007 12:51:14 +0200, Georg Bauhaus wrote: > > > On Mon, 2007-09-03 at 09:53 +0200, Dmitry A. Kazakov wrote: > >> On Sun, 02 Sep 2007 23:37:33 +0200, Georg Bauhaus wrote: > >> > >>> Suppose every package is reusable. > >> > >> That's the goal. > > > > Why? > > In order to get a better understanding of the problem and solution. What, exactly, is the improvement in understanding a given problem that involves one House and one Barn? The fact that by way of scholastic sophistication we can think of all kinds of combinations of many Barns, or Houses? What is the gain in coming up with types summarizing things that just are not present in the problem domain? Should we have to rewrite the descriptions of our models until the goal of achieving all-package-reusability can be reached? (I know that programming just a little more than what is necessary for solving the given problem can be beneficial. The solution may gradually become much less simple, though. Difficult to understand, that is!) > > The "abstract state machines" kind of package (as opposed > > to those packages framing an "abstract data type") do work well > > in Ada program without a type parameter; it doesn't carry > > any additional information of spectacular use. > > It is difficult to see how an abstract state machine is not a type. Ada type or DK type? Certainly packages can have seen to have "qualities" that Ada types happen to have as well, e.g. exposing an "interface" in the non-Ada sense of the word. A singleton will have this kind of interface. A type defined in the corresponding package changes little in this regard. > For dynamic scoping there exit blocks. We cannot replace blocks by > packages. So let blocks rule. The only possible reason for nested packages > is the language regularity: if a package can be nested in another package, > then it should be allowed in any declarative scope. Probably even between > "for" and "loop"! (:-)) But if you removed nested packages altogether you > would probably notice no miss. Because it is only static nesting which is > really needed, and that is covered by the child packages. Well, so what? Can I use a package declared within a procedure as a match for a problem domain object? It seems quite reasonable to me to do so when a local package is an easy way to deal with lifetime, modularization, and visibility at the same time.