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: Georg Bauhaus <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Top 10 Worst C# Features
Date: Thu, 3 Sep 2015 10:14:35 +0200
Organization: A noiseless patient Spider
Message-ID: <ms8ve0$57u$1@dont-email.me>
References: <alpine.DEB.2.20.1509021228510.5314@debian>
 <ms7j9r$ho$1@loke.gir.dk>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 3 Sep 2015 08:12:48 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
	logging-data="5374"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18Km3cJrQWvr/t/TJMiwpsANWymk4J0eYk="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
In-Reply-To: <ms7j9r$ho$1@loke.gir.dk>
Cancel-Lock: sha1:c3tSbviMIVsRrY2Q+XzArTH4s1g=
Xref: news.eternal-september.org comp.lang.ada:27690
Date: 2015-09-03T10:14:35+02:00
List-Id: <comp.lang.ada>

On 02.09.15 21:39, Randy Brukardt wrote:
> "[they] run
> deterministically, run on the current thread, and never run on partially
> constructed objects."
> Moreover, they always run when objects are destroyed, while apparently in C#
> they don't run for explicit calls to Dispose.

Still, finalizers are an accidental bit of design. It uses just scopes
and it involves garbage. And while that's something, this very bit is
being carried to the limit, perhaps too far: if finalizers are popular,
problems pop up with corresponding frequency.

What finalization can presumably solve I'd love to see addressed
systematically, using language that attaches life cycle events to
types. Events addressable in the type's very definition, not attached
by implication, testament style, about things to happen while objects
are dying. Events becoming part of the type definition, the program
then makes the objects react to events while they are still alive and
well. Actions will no longer be some "last words" that require
additional efforts to get right.

Is it possible to produce a scheme that makes attaching "event
subprograms", say, well defined? Maybe permissions would be based
on visibility of entities referred to?

For a start, using subprograms,

    type T is ...
    for T'Some_Event use ...

or

    type T is ...
    with T'Some_Event => ...

When new attachments would be desired in deeper scope, maybe one could
use some type derived there.