Re: High-Integrity OO and controlled types

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

On Wed, 04 May 2011 10:48:14 +0200, Georg Bauhaus wrote:

> On 5/3/11 6:28 PM, Dmitry A. Kazakov wrote:
> 
>>>> 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.
> 
> Could there be a workable design that lifts these two
> events (entry, exit) to proper, programmable, abstractions
> and how would they be connected to all of the language,
> not just the types section?

Yes, these are called constructor and destructor of the type. They are not
bound to any given scope, because:

1. the actions to perform are independent on the scopes;
2  a scope-bound design would mean distributed overhead, being fragile,
non-reusable, non-testable. [In the HI context it is especially bad.]

In its essence it is untyped, because a type meant to maintain its
properties independently on the number of instances and scopes of these
instances (nested to the type's scope of course).

> By analog I meant this: The way a nested object goes out of
> scope may influence objects in some less nested scope.

Which implies some links between objects, which itself is a model breach,
because it introduces references (access types, handles, mix-ins). Such
designs must be avoided in first place, as perpetually repeated in c.l.a.,
don't use pointers if you don't need to.

> Then, is it (a) possible, (b) feasible, (c) good ROI
> to design types that are interconnected to reflect all
> possible effects between types, in the types?  Wouldn't this
> design mix aspects of operation that should be kept in a different,
> yet connected formalisms that makes explicit use of scopes?
> 
> As a simple example, I had been considering a relatively global
> array or set shared between two procedures or tasks;
> each proc/task would be responsible for part of the
> elements in the shared data structure.  When one fails,
> the the "exit action" is to "reset" its share of slots/
> elements.

This does not read as a complete description. In what sense are the parts
of the array shared? If sharing means only independent use of the parts,
then what sense has the array as an object in this design? Independently
used parts must be local to their users. Now, if there is something else
behind this, i.e. that parts are sometimes used independently and sometimes
together, then too little is said about the mechanisms used for the latter,
and most intricate part of design.

> This sounds like one could design types that
> do(!) just this as part of their finalization.  But it does
> seem like an awful lot of overhead, and is essentially
> a type that is-a procedure.

You see that as an overhead only because the picture is incomplete. Once
you fill the gaps, you will see how "exit action" firs there. That would
definitely involve additional objects, e.g. controlled "handles" of which
finalization would deal with "exit" and other operations would serve
interlocking etc.

> My question then is whether
> or not this overhead is worth it, at least at this fairly
> low level of small algorithm writing, not system design.

See, low-level is what "finally" is.

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