Re: Reprise: 'in out' parameters for functions

[wojtek@power.com.pl (Wojtek Narczynski)]

Dimitry,

You silently refused to say what abstraction inversion is according to
you :-)

> However it is questionable, whether protected objects have a higher level of
> abstraction than semaphores. They are more generic but no less fundamental.

Well, let's look at them as manual (semaphores) vs. automated
(protected objects).

> BTW, for your protected counters example, (4) would be enough:
> 
> protected type Counter is
>    procedure Inc; -- Increments this counter
> private
>    Value : Integer := 0;
> end Counter;
> 
> procedure Inc_One (First : in out Counter);
>    -- Same as Inc, but uses functional notation
> procedure Inc_Two (First, Second : in out Counter);
>    -- Increments two counters atomically, starts two protected actions,
>    -- one per argument

Cool. 

> First of all I do not count compile time solutions for true solutions. A
> true one would include an ability to work with dimensioned values which
> units are unknown at compile time. A simpliest possible example is to write
> a physicist calculator.

Then we're talking about two distinct things. I am talking about a
compile time solution only.

> OK, there are only two ways I know of, if you find a third way...

The first way can be viewed as an incarnation of the second. 

Or you can ensure that there are no runtime exceptions.

> How it differs from (2)? You just replaced the official mechanism of
> inheritance with some hard-wired other. Discriminants are just special kind
> of members.

It differst in that it can be implemented, because there are no
pointers to inexistent trampolines, only (immutable, integer) values.

> This won't work. The exception out of Catch_It will be propagated *after*
> "end Sample". So you cannot catch it here! In any point you could, the type
> B will be already finalized. So you would have a zombie object of an
> unexisting type.

Well, this is how it goes with exceptions. That's why the "type"
should be limited (in ordinary sense) to only: declaration, raising /
construction, catching and extracting immutable values in handlers.

> Why (1) cannot work here? The only real problem with (1) I can see, is that
> the exception type does not have ranges or other forms of subsets. One need
> some syntactic suggar to define a set of exceptions which could be then
> named in "when".

Feel free to perceive my 'code' as syntactic sugar.

Regards,
Wojtek