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,8591be732d0fce98 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 25 Jul 2008 10:47:49 +0200 From: Georg Bauhaus Reply-To: rm.tsoh+bauhaus@maps.futureapps.de User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada OOP alternatives? References: <462e0cf4-1d53-4918-b30b-dd3d8df90f1b@p25g2000hsf.googlegroups.com> <487d9636$0$6543$9b4e6d93@newsspool3.arcor-online.net> <6e5uq2F5g7n6U2@mid.individual.net> <1y046u74vmwh3.19jm2fcdx5xpt.dlg@40tude.net> <5ob7w7usrc74$.kms2e1vqs4k0.dlg@40tude.net> <48883529$0$18826$9b4e6d93@newsspool2.arcor-online.net> <48883f41$0$18829$9b4e6d93@newsspool2.arcor-online.net> <6i1s0y8eeka.121ek9qcgunha$.dlg@40tude.net> <48885757$0$18818$9b4e6d93@newsspool2.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <48899335$0$18824$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 25 Jul 2008 10:47:50 CEST NNTP-Posting-Host: a4c96262.newsspool2.arcor-online.net X-Trace: DXC=6=?3mAPIZBV@>[RYkFXOIPA9EHlD;3YcR4Fo<]lROoRQ4nDHegD_]RU8BT:8XPOBmPA:ho7QcPOVSIF13WGY9R<]iO0M>`3N:eS X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:1321 Date: 2008-07-25T10:47:50+02:00 List-Id: Dmitry A. Kazakov wrote: > On Thu, 24 Jul 2008 12:20:07 +0200, Georg Bauhaus wrote: > >> Dmitry A. Kazakov wrote: > >>>>> then in 80s, but it is no any problem now. IDEs do it better. >>>> Ada IDEs cannot affect semantics? >>> I am not sure what you mean... GPS does affect the semantics when you >>> change some project options. >> I meant the semantics of child packages and separate units >> as given in the program text. > > I lost your point. Can you elaborate it a bit more? package News23 is type T is null record; procedure Op(Item: T); end News23; package body News23 is procedure Special_Case(Item : T); -- Makes XYZ(Item) known to neighbouring Funnix process Foo procedure Op(Item: T) is begin if True then -- imagine real life conditional here Special_Case(Item); end if; end Op; procedure Special_Case(Item : T) is separate; end News23; with Ada.Text_IO; -- or some Sockets, or .... with All_Kinds_of_Things_Neccessary; -- for the special case separate(News23) procedure Special_Case(Item : T) is begin null; end Special_Case; Observation 1: Suppose you try to use an IDE in place of "separate", to hide away the details of Special_Case. Then the dependences on the with'ed package Ada.Text_IO and on All_Kinds_of_Things_Neccessary will have to be listed for the entire package. So IDEs cannot help with dependences. You need separate units or child packages. Observation 2: The single Special_Case procedure will serve its purpose by informing the other (Funnix) side as needed. Now instead of just the procedure Special_Case, which does what is needed, I could construct an ADT Special_Process. This type should, IIUC, reflect a general Special-Case-Communications idea so 1/ it matches the other side and 2/ is an ADT (reusable?). package The_Far_Away_Company is subtype Code is Natural range 200 .. 599; type Message is new C.char_array; function To_Special_Message(ID: Code; Message: String); type Special_Process is private; procedure Send(The_Process: Special_Process; The_Message: Message); end The_Far_Away_Company; What amount of work is needed to make this reusable? I'll just pack it into the local part of a very private single-purpose procedure separated from the others in the body. Granted, there are cases when a child package seems a much better choice. For example, when the special communications procedure needs to maintain state information that is of no concern to any other subprogram anywhere. >> Why, e.g., build an entire type when a single procedure >> is sufficient, and will be sufficient in the future? > > How can you know that? Sometimes the future of a program is known. For example, known to end, because the strange device is no longer produced and the support has ended. The special case procedure dies with the special case device/program. >> Many languages have a function type >> built in, functions are objects. > > But not in the sense of a stateful object of OO. Yes, there are function objects in the sense of a stateful object of OO. They even have execution in steps, and can refer to relatively global objects that might be updated during (virtually) stepwise execution of the function.