Re: High-Integrity OO and controlled types

[Maciej Sobczak <see.my.homepage@gmail.com>]

On May 3, 11:32 am, Cyrille <co...@eu.adacore.com> wrote:

> > Excluding controlled types altogether sounded like throwing baby out
> > with the water, but now the motivations are a bit more clear to me.
>
> HI profiles are usually much more constrained. The first goal of this
> document is to gather the necessary information to make it possible to
> build a safety case when using tagged types and more generally OOP in
> a HI context. Usually those are banned along with almost all the
> "advanced" features of the language. So no baby thrown with the water.
> This is a the other way around: we put more water in the bath so that
> maybe one day we can consider bathing your "controlled" baby ;-)

I see. Note that between these two:

1. dynamically allocated class-wide (with open hierarchy) objects tied
to locally scoped storage pool with all resulting mess, and

2. limited controlled object on the stack as a way to hook scope exit
event

there is a *wide* spectrum of use cases, some of them being
unreasonable in the HI context, but some of them being entirely
justified.

I would very much welcome at least that second extreme above being
acknowledged as a valid programming pattern in safety critical
systems.

Another angle: the fact that the lack of controlled types in HI
profiles can be considered as a problem is entirely a result of the
fact that Ada completely screwed this aspect at the beginning.
Controlledness should not be based on tags - it should be a completely
orthogonal property of the type, without any relation to class-wide
objects and dispatching calls (see C++ for an example). Interestingly
this conclusion comes up regularly. Time to fix that part of the
language, perhaps? ;-)

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com