Re: Ada 2005 puzzle

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

On Fri, 20 Jul 2012 04:30:27 -0700 (PDT), in comp.lang.ada you wrote:

> W dniu pi�tek, 20 lipca 2012 10:27:15 UTC+2 u�ytkownik Dmitry A. Kazakov napisa�:
> 
>> The problem is that a *new* limited object cannot be result of a function,
>> this is conceptually broken.
> 
> Yes, we have already concluded long time ago that one of the priorities
> for Ada is to fix the concept of object construction.

we = you and me? I bet 99% of c.l.a still firmly believe that functions 
returning limited objects were all OK.

> But in this case I think that Ada has everything that is needed.

On paper. But practically (because the concept is bogus) I suspect that 
there is no way to make it working in real-life scenarios. I cannot count 
number of cases when I was forced to redesign because of the damn problem. 

If Randy himself, who is a compiler designer and language lawyer, gave up, 
what would you expect from laymen?

>> The factory of limited objects passed to
>> Insert must provide means to:
>> 
>> 1. determine the constraints of the object (using some set of arguments);
> 
> This is not the container's business and will usually come with the
> factory itself - or from the context of the factory. That is why I expect
> this to be used with access to *local* functions, which can drag along all
> the information that is needed to construct the object.

Yes, this one of possible forms of factory.
 
>> 2. construct the object in place (using the arguments again);
> 
> Same as above - the constructor function can bring the "arguments" from
> its surrounding context. You can even create wrappers like this:
> 
> procedure Insert_From_Arguments
>    (C : in out Container;
>     X : in Integer; Y : in Integer; Z : in Integer) is
> 
>    function Construct return T is
>    begin
>       return V : T do
>          V.X := X;  -- constructing T from arguments X, Y, Z
>          -- ...
>       end return;
>    end Construct;
> begin
>    C.Insert (Construct'Access);
> end Insert_From_Arguments;
> 
> Above, the arguments are passed as part of the Construct's environment.
> 
>> 3. optionally, construct the class-wide object upon the specific object
>> (using the arguments)
> 
> I expect that class-wide is what the container sees (for example, by being
> instantiated with such a type) - the rest happens the usual way, by
> initializing the class-wide placeholder with specific constructed object.
> This way you could naturally have a container of OO objects.

I meant here a different thing. If you have some dispatching operations to 
be performed upon initialization, these must be called on the class-wide 
instances, when all ancestors are already initialized.

Let you have a hierarchy of types  T1:>T2:>T3. Then construction should run 
as follows:

stage 1
T1 constraints evaluation
T2 constraints
T3 constraints

allocation

stage 2
T1 initialization
T2 initialization
T3 initialization

stage 3
T1'Class initialization, only here we could dispatch on T1'Class
T2'Class initialization
T3'Class initialization

>> 1-3 cannot be effectively fused into single operation
> 
> Why? What's wrong (ie. what is ineffective) with the above?

ARG tried and failed.

The technical reason IMO is that steps 1,2,3 are intermixed. This prevents 
encapsulation of T1/1 + T1/2 + T1/3 into single subprogram. Furthermore at 
the stage 1 there is no any object allocated. It cannot be an argument. 
Stage 2 needs a type-specific argument. Stage 3 needs a class-wide 
argument.

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