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,4e5770c49b971630 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!87.79.20.105.MISMATCH!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: High-Integrity OO and controlled types 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: <679e3217-98dd-43c1-86f6-2038a029c3ea@b19g2000yqg.googlegroups.com> <94f3a272-d071-4a74-bfbd-8f2b4c2347cf@m10g2000yqd.googlegroups.com> <4dbfe6cc$0$7664$9b4e6d93@newsspool1.arcor-online.net> <1in9ypl17vu1t$.1shivr91x8zw6.dlg@40tude.net> <4dc01dca$0$6885$9b4e6d93@newsspool2.arcor-online.net> <1ds39akl3dbii$.mlyj7piip5o3.dlg@40tude.net> <4dc112cf$0$6772$9b4e6d93@newsspool3.arcor-online.net> Date: Wed, 4 May 2011 11:28:44 +0200 Message-ID: NNTP-Posting-Date: 04 May 2011 11:28:44 CEST NNTP-Posting-Host: bfd75f7b.newsspool1.arcor-online.net X-Trace: DXC=C>;=2N3EQH3_A0jCfgHO6>ic==]BZ:af>4Fo<]lROoR1<`=YMgDjhg2^0\f^MK@8?9[6LHn;2LCV>7enW;^6ZC`4\`mfM[68DC3B5:^JblWZG0 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:19152 Date: 2011-05-04T11:28:44+02:00 List-Id: On Wed, 04 May 2011 10:48:14 +0200, Georg Bauhaus wrote: > On 5/3/11 6:28 PM, Dmitry A. Kazakov wrote: > >>>> Actions as amorphous chunks of code tossed here and there depending on >>>> scope is a way different ["anisotropic"] approach. In particular it does >>>> not fit into safe modular software design, because of this "anisotropy". >>> >>> What will type-object/module code look like if it is equivalent >>> to its nested analog? Better? >> >> Analogue of what? The point is that "finally" cannot replace initialization >> and finalization of objects, specific or class-wide. > > Could there be a workable design that lifts these two > events (entry, exit) to proper, programmable, abstractions > and how would they be connected to all of the language, > not just the types section? Yes, these are called constructor and destructor of the type. They are not bound to any given scope, because: 1. the actions to perform are independent on the scopes; 2 a scope-bound design would mean distributed overhead, being fragile, non-reusable, non-testable. [In the HI context it is especially bad.] In its essence it is untyped, because a type meant to maintain its properties independently on the number of instances and scopes of these instances (nested to the type's scope of course). > By analog I meant this: The way a nested object goes out of > scope may influence objects in some less nested scope. Which implies some links between objects, which itself is a model breach, because it introduces references (access types, handles, mix-ins). Such designs must be avoided in first place, as perpetually repeated in c.l.a., don't use pointers if you don't need to. > Then, is it (a) possible, (b) feasible, (c) good ROI > to design types that are interconnected to reflect all > possible effects between types, in the types? Wouldn't this > design mix aspects of operation that should be kept in a different, > yet connected formalisms that makes explicit use of scopes? > > As a simple example, I had been considering a relatively global > array or set shared between two procedures or tasks; > each proc/task would be responsible for part of the > elements in the shared data structure. When one fails, > the the "exit action" is to "reset" its share of slots/ > elements. This does not read as a complete description. In what sense are the parts of the array shared? If sharing means only independent use of the parts, then what sense has the array as an object in this design? Independently used parts must be local to their users. Now, if there is something else behind this, i.e. that parts are sometimes used independently and sometimes together, then too little is said about the mechanisms used for the latter, and most intricate part of design. > This sounds like one could design types that > do(!) just this as part of their finalization. But it does > seem like an awful lot of overhead, and is essentially > a type that is-a procedure. You see that as an overhead only because the picture is incomplete. Once you fill the gaps, you will see how "exit action" firs there. That would definitely involve additional objects, e.g. controlled "handles" of which finalization would deal with "exit" and other operations would serve interlocking etc. > My question then is whether > or not this overhead is worth it, at least at this fairly > low level of small algorithm writing, not system design. See, low-level is what "finally" is. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de