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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,147f221051e5a63d
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!storethat.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 19 May 2008 15:18:48 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: memory management in Ada: tedious without GC?
References: 
 <4ddef8bf-b5b1-4d7e-b75b-386cd6c8402c@l17g2000pri.googlegroups.com>
  <9f2c2db4-d6c1-4cdf-884c-5cbc26ac7701@d1g2000hsg.googlegroups.com>
 <d94612cf-d2f1-49ce-a327-46653487dd99@l42g2000hsc.googlegroups.com>
 <1qxcw3pphdlek.1jgsfwb7atdmo.dlg@40tude.net>
In-Reply-To: <1qxcw3pphdlek.1jgsfwb7atdmo.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <48317e39$0$7550$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 19 May 2008 15:18:49 CEST
NNTP-Posting-Host: a9667a5b.newsspool1.arcor-online.net
X-Trace: 
 DXC=2?I2?R>ioIH[6=1B@oB@@@ic==]BZ:afN4Fo<]lROoRA<`=YMgDjhgB;E;fM<>:D0Inc\616M64>JLh>_cHTX3jM6^oBbb7KYOB
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:239
Date: 2008-05-19T15:18:49+02:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov schrieb:
> On Sun, 18 May 2008 20:50:48 -0700 (PDT), Matthew Heaney wrote:
> 
>> On May 16, 4:42 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>>> In Ada RAII is realized with controlled types. They are severely
>>> broken in that they are intrusive in the type hierarchy and they burn
>>> the whole budget for implementation inheritance,
>> No, this is wrong.  You can add in Controlled-ness as far down the
>> hierarchy as you like, by adding a controlled component.
> 
> This is broken too:
> 
> 1. You don't know exactly the order in which the Finalize of the controlled
> component gets called.  So if you access the container object over an
> access discriminant, that might be already invalid.

When you design a type T, should the aspects of "death"
of an object affect the "live" aspects of T objects at all?
Death happens at a defined moment. What happens at this
moment is conceptually separate from what happens while
the object is alive, even though there are relations
between births, lives, and deaths, of course.

But why lump together these two aspects of dynamics in the
same type?
Why not have types, task types perhaps, that take care
of the post mortem affairs of related types? (Other than
wasting the bits maybe.)

We have Factories. Why not have Incineration_Plants or
similar, with well defined protocols?
I certainly find it strange having to think of the
topological orderings of cleanup work when I focus on
what objects of a type should actually do (to do ==>
still alive).