Re: Top 10 Worst C# Features

[Georg Bauhaus <bauhaus@futureapps.invalid>]

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.