Re: High-Integrity OO and controlled types

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 03 May 2011 17:22:50 +0200, Georg Bauhaus wrote:

> On 03.05.11 14:27, Dmitry A. Kazakov wrote:
>> On Tue, 03 May 2011 13:28:12 +0200, Georg Bauhaus wrote:
>> 
>>> On 03.05.11 11:59, Maciej Sobczak wrote:
>>>
>>>> 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,
>>>
>>> Actually, in non-flat languages like Ada, scope exit
>>> actions should be based on scopes, not (just) types,
>>> as types can effectively span multiple scopes.
>> 
>> But typed languages tend to consider actions as operations defined on
>> types, with certain contracts, reusable, clearly bound effects etc.
>> 
>> Actions as amorphous chunks of code tossed here and there depending on
>> scope is a way different ["anisotropic"] approach. In particular it does
>> not fit into safe modular software design, because of this "anisotropy".
> 
> What will type-object/module code look like if it is equivalent
> to its nested analog?  Better?

Analogue of what? The point is that "finally" cannot replace initialization
and finalization of objects, specific or class-wide.

The opposite is wrong. Any example where "finally" might be useful is
motivated by improperly designed types, e.g. File_Type, which does not
close itself upon destruction.

> My guess is that to achieve the necessary linking, one passes
> Italian food handles to constructors and/or established registries
> that receive "events" like "a scope X has been left".

See above, you need not to handle scopes. Scopes are ad-hoc, used for the
purpose of defining the lifespan of some objects. Leaving scope is as event
as leaving loop, leaving the else alternative of an if etc. If you need
such events re-design!

> For example, assuming something like the naturally nested
> Integrate function.

BTW, integrating function is an object. For this object the compiler
generates finalization, which in particular kills the closure. Care to show
how to do this using "finally"?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de