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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Things that OO programming lacks Date: Tue, 18 Nov 2014 20:18:49 +0100 Organization: cbb software GmbH Message-ID: References: <10d9w.55626$8w1.22302@fx12.iad> <150er0b62wsh3$.1xabmp81w5kdw.dlg@40tude.net> <1azsoc77wjhmi$.1grmnnlq033tz.dlg@40tude.net> <5yzci4a8snfg.1dfsqjyvneeym$.dlg@40tude.net> <1dqj0bjtbadcq$.150sjuwku2zbk$.dlg@40tude.net> <55b6ald1m6ow$.1rho1th3fqrgm.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: wfRpp7ltpEWhI2na6kgpfA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:23526 Date: 2014-11-18T20:18:49+01:00 List-Id: On Tue, 18 Nov 2014 19:50:23 +0100, G.B. wrote: > On 18.11.14 14:42, Dmitry A. Kazakov wrote: >> That is not a language term, so far. And unlikely it would. > > But OO is still lacking such terms, right? No. You didn't presented any. If you did, you should also show why it would be impossible or difficult to express the thing as an object, operation etc. >> Relation is a logical term. > > Which is why I preferred relationship, which is more open > to new interpretation. I don't see which relationships between specifically objects were useful while incomputable. Some relationships are non-terms on purpose, some are computable but undesirable (e.g. Unchecked_Conversion stuff). So you should also show usefulness and preservation of abstraction. >>> But since for the reasons you named (when mentioning Post-Turing) >>> we shy way from Boolean valued operations for everything, why not invent >>> something that expresses what programmers need to known in order to make >>> those answers? >> >> To which questions? > > To those listed so far. Variations of things, tiny or not: > > "Why did the effect of Obj_1's doings occur before those of Obj_2's? What is effect of an object? It is breaking abstraction at least. All effect of an object is in its state. That is the fundamental principle of OO decomposition. > (Some say, I think, that event aware object oriented systems > are (worth) a new paradigm waiting to be formalized for the > very reason that those FSMs and global variables are nasty, > be they dressed as OO or not.) Why event is not a primitive operation or not an object? >> I suppose you are confusing relationships between objects with >> relationships between types and correctness statements. > > I don't think that time is involved in a relationship between > types in general, or can I express that relationship in Ada OO types? Why should you? Time aspects are almost never functional and thus do not belong to types. > There are cases where in Ada I can approximate order of types > in time, so to speak, thanks to nesting: > > procedure Stage_0 is > type T is ...; > begin ... > end Stage_0; > > procedure Stage_1 is > type T is ...; > begin ... > end Stage_1; > begin > Stage_0; > Stage_1; > > Due to the order of calls, it is now fairly certain that objects > of type Stage_0.T all exist and "cease to exist" before any object > of type Stage_1.T starts to exist. > Is this conclusion(!) perfection of expressiveness already? I see. You are confusing correctness with the language. In procedural and OO decomposition when anybody chooses to factor out two procedures like Stage_0 and Stage_1 these are designed independent. This is again a fundamental design principle of minimal coupling. If the client of these entities, carefully observe, this is a third party, needs to call them in a certain order, that must follow from the pre-conditions and post-conditions of these procedures. This is what makes Stage_1 Stage_0 incorrect and Stage_0 Stage_1 correct. Under other circumstances the conditions might evaluate differently making other orders correct. If you don't like this you should use different decomposition, not procedural or OO. Which is the point. The paradigm goes first. > I suppose I'm thinking merely in term of objects, not just OO-ish, > but just objects that have identity, and any property, shared or > emerging, that is derived from the formal properties of the objects, > the program, as well as from the interpretation of (non-OO-)objects > discussed by the people involved. No idea what this means. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de