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,e859f774bbb3dfb3 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!news.astraweb.com!newsrouter-eu.astraweb.com!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: another way to shoot yourself in the foot? 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: <54157920-377a-441b-9b0b-f0c4f9ddffec@f36g2000hsa.googlegroups.com> <54435596-5e7f-4686-a2b7-1e22d7c4b186@p25g2000hsf.googlegroups.com> <483ugmvkl2ea.1hrqsq7ru4t1x$.dlg@40tude.net> <12dhu8e1w5ac9.1s9hzkf9d2rsy$.dlg@40tude.net> <3bc1018b-b275-4a59-8302-6a3262766f63@z24g2000prf.googlegroups.com> <6ug5vhz5j1e4$.1lqpd52jz6qry.dlg@40tude.net> <1s88o46xl9o9b$.1e88zxl9es93z$.dlg@40tude.net> <486184b7$0$6615$9b4e6d93@newsspool2.arcor-online.net> Date: Wed, 25 Jun 2008 10:09:16 +0200 Message-ID: <1ilzy5ufjyn6p$.cu5078bqe0mj$.dlg@40tude.net> NNTP-Posting-Date: 25 Jun 2008 10:09:16 CEST NNTP-Posting-Host: 43a474c9.newsspool1.arcor-online.net X-Trace: DXC=;hdbLbBmn^;;]cDoEWD6A4ic==]BZ:af>4Fo<]lROoR1<`=YMgDjhg23Geomji7S<5[6LHn;2LCV>7enW;^6ZC`4IXm65S@:3>?MiBTB32V[J2 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:866 Date: 2008-06-25T10:09:16+02:00 List-Id: On Wed, 25 Jun 2008 01:35:17 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > >> The enclosing object does not expect >> its components to prematurely finalize themselves. It is just a bad design >> turned upside down: > > It seems like everyone wishes to force dynamic context > information to be expressible as static type features, > together with implicit callback operations from > Controlled'Class. I am not sure what you mean. The problem of Ada is that some types are more types than others. There shall be no such irregularities. > Why not use plain old scopes when establishing context > for objects? Egh? Are you going to throw record and array types out of the language? Back to 60s? (:-)) > Or generic elaboration. > > Is anything wrong with having all of lifetime, startup and > cleanup of objects controlled by a combination of: nesting, > making calls, handling exceptions, and scoping? Again, I am not sure about the meaning of above, but the lifetime of an object is controlled by the relation to its "master." Whether the master is the scope of a block statement or the scope of the enclosing object is not that relevant. > Would Finalize be superior when calls from within it will > have to refer to all kinds of other data anyway, > even indirectly? It *shall* be. It is merely a matter of contract. When Finalize is an operation of the type T, then necessarily, the object passed to it must be of T. The rest follows. > The Controlled subprograms are linked to a single type. But, but it is a poor design. Constructor/destructor is bound to the class, obviously. A class is a set of types. > From what I know about Aspect Oriented Programming, it shows > that building modules around a single type does not always > yield the right abstraction: When the thing is seen from a > different angle, the type should have a different interface. > From yet another viewpoint, the type's operations should > cooperate differently. In still another perspective > some abstraction is not represented by this type alone. > Instead, it would be represented by some combination of > this type and another type. I am sorry, but this makes no sense to me. Forget about Ada's interfaces. Interface is a [abstract] type, period. Whatever interfaces an object might fulfill, they all are supertypes of the object's type. Where is a problem? > And now automatic operations like Initialize and Finalize, > hooked on a single type (and possibly discriminants---does > GNAT like at last :-) are supposed to be the solution of > all data management? Yes they are. Note that constructing/destructing hooks have different rules of composition, like aggregates and assignments have. They are not overridden they are extended. (Ada's Finalization is bogus, alas). Technically S derived from T has a constructor. This constructor is generated by the compiler. It has hooks in order to initialize S and T. The hook of T is called before the hook of S. If S'Class is constructed. Then two new hooks are called: 1. T -- post: can use it as T 2. S -- post: can use it as S 3. T'Class -- post: can use it as T'Class, e.g. dispatch to the methods of 4. S'Class -- post: can use it as S'Class, e.g. dispatch -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de