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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Things that OO programming lacks (was: What exactly is the licensing situation with GNAT?) Date: Fri, 14 Nov 2014 16:29:56 +0100 Organization: A noiseless patient Spider Message-ID: References: <084b1934-9641-425e-85ec-293e0334413e@googlegroups.com> <86bf69c8-eb08-4696-b6c9-3784f5c42213@googlegroups.com> <87389olqie.fsf@ixod.org> <10d9w.55626$8w1.22302@fx12.iad> <150er0b62wsh3$.1xabmp81w5kdw.dlg@40tude.net> <1azsoc77wjhmi$.1grmnnlq033tz.dlg@40tude.net> <5yzci4a8snfg.1dfsqjyvneeym$.dlg@40tude.net> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 14 Nov 2014 15:29:43 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="18385"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19SRV6f5rkRCTOZyxolXFmh2YXb5wHM2xE=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <5yzci4a8snfg.1dfsqjyvneeym$.dlg@40tude.net> Cancel-Lock: sha1:RwfYkOR5O45kn2ANDgsQ1mTrZ+w= Xref: news.eternal-september.org comp.lang.ada:23297 Date: 2014-11-14T16:29:56+01:00 List-Id: On 14.11.14 14:35, Dmitry A. Kazakov wrote: >> That's the theory. But in practice, having all the hard stuff written >> >already just promotes cutting and pasting of a different color. The code >> >that*uses* those classes is normally not reusable. That's what is cutting >> >and pasting. It's been shoved down a level or two. > Maybe. But, again, what would be better? Better? A mode of expressing what we know beyond our objects, in dedicated language: Since programmers are starting to know more about patterns of connecting objects, I suppose something expressing those patterns more clearly would be useful. For example, "connections" may refer to order of calls in time, and to "flow" caused by "data". A way to express these patterns of OO programming will avoid producing intractable state manipulation code (a.k.a. spaghetti). OO does not prevent programmers from just operating setters and getters, "knowing" the effects this has on the "other" object. When a programming method using patterns relies on naming and conventions, like the GoF patterns do, that's not language, is it? Another important example is events. Consider a system with many inputs, many outputs, and also some treads. A GUI program, or a control unit, an OS, etc. There will be events in need of a response. Events are generated either by programs or by the world. Then I want to express, at the language level, using dedicated source text: - What are all of the events than can have a normal effect on the program? - What are the possible orders of these events? - How can I arrange for orders of events to be know at or after run time? - How can I connect events expressly to objects that respond to the events? - How can I learn, by looking at specific language in a program, which objects are connected to an event? At first, Ada's task type seem to covers order of events, in bodies (only?). Using the control structure of the language facilitates expressing possible orders: task body ... is begin ... accept first_this; ... accept then_that (...) ... loop select accept either_A (...) ... or accept or_B (...) ... end select; end loop; end ; But this is only half way, since task objects' definition does not, by design, show possible connections of multiple task objects in a program. The other side, that of calling tasks (selectively) adds to the complexity of analysis. Similarly, there are ways to place a restriction on the order of subprogram calls. For example, one might force an order by having a sequence of functions consume and produce objects from an ordered sequence of types: function A (Obj : T0) return T1: function B (Obj : T1) return T2: ... function M (Obj : T16) return T5: ... Or one could be using condition expressions, like in procedure P (Object : in out Typ; ...) with Pre => Object.State (State_No'(4711)); function State (Object : in Typ) return State_No; but both are not specific language, and at least the second, i.e. Pre referring to object state, require mere conventions. To me these look like a poor workarounds, Pre more than the types TK, even when they assist the client programmer writing calls of subprograms in proper order. Which only shows that a way to express order, e.g. in interfaces, is valuable. To have language for expressing connections in a program would be better. We only got tools that show graphs of a few arrows, as in design diagrams for interfaces and models. But we do not really have source text specifically addressing order of events, and connections made on the occasion.