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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news4.google.com!feeder3.cambrium.nl!feeder1.cambrium.nl!feed.tweaknews.nl!news2.euro.net!feeder.news-service.com!newsfeed.freenet.de!news.tu-darmstadt.de!news.belwue.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Self pointer in limited record Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> <1188851929.2630.85.camel@kartoffel.vocalweb.de> Date: Tue, 4 Sep 2007 10:24:36 +0200 Message-ID: NNTP-Posting-Date: 04 Sep 2007 10:24:10 CEST NNTP-Posting-Host: 8339f848.newsspool1.arcor-online.net X-Trace: DXC=`;KKlX8:B1^U6b:FjPaGjQic==]BZ:af^4Fo<]lROoRQ4nDHegD_]RUOYLSG<2noRPDNcfSJ;bb[UIRnRBaCd On Mon, 03 Sep 2007 22:38:49 +0200, Georg Bauhaus wrote: > 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? Wow, are you arguing against understanding or just against reuse and refactoring (used in order to achieve it)? > Should we have to rewrite the descriptions of our models > until the goal of achieving all-package-reusability > can be reached? Yes, this is a part of normal software developing / evolving cycle. Or do you have write-once applications in mind? > (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!) Abstraction, normally reduces, complexity, provided that a better understanding was indeed achieved... >>> 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. I don't follow you. There are five things, all different: 1. Abstract data type 2. Package 3. Singleton 4. State machine 5. Abstract state machine I don't see why you take for granted that 2 = 4 or 5. Package is not a state machine, at least if you don't want to reduce everything to machine code. Even less is it an abstract state machine. > Can I use a package declared within a procedure as a match for a > problem domain object? Packages are not for modeling individual objects. > 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. Nonsense. When you want to use a package as a model of something, then all your words about lifetime, modularization, being local etc become meaningless. These are solution-specific properties irrelevant to the thing being modeled. You have to talk about the domain problem properties. Which properties of the domain are modeled by a package? Solve at least one *domain* problem using a package, only package and nothing but package. See? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de