From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d1df6bc3799debed
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Syntax for tagged record types (was Re: Not intended for use in
 medical,)
Date: 1997/05/24
Message-ID: <EApCsn.Fsy@world.std.com>#1/1
X-Deja-AN: 243668876
References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com>
 <mheaney-ya023680002305970103110001@news.ni.net>
 <JSA.97May23142418@alexandria> <33867D87.21BA@sprintmail.com>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-05-24T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <33867D87.21BA@sprintmail.com>,
John G. Volan <johnvolan@sprintmail.com> wrote:
>This then allows a user to construct a value of the given type during an
>object declaration, in the initialization part:
>
>   Some_Value : Some_Value_Type := Make_Some_Value (...);

This sort of thing could make sense for limited types, too -- as others
have pointed out, Ada *confuses* initialization and assignment.
However, it seems tricky to implement:

    type T is limited
        record
            A_Task: Some_Task_Type;
            ... -- etc.
        end record;

    function F return T is
        ...
    begin
        ...
        declare
            Result: T;
        begin
            return Result;
        end;
        ...
    end F;
    
    function G return T is
    begin
        ...
        return F;
        ...
    end G;
    
    X: T := G; -- Not Ada.

If the above were legal, the compiler would need to allocate the
deeply-nested Result object in a non-nested place (on the heap?), since
it would "become" the object X.  No fair copying Result into X, since
the type is limited.  The seems a bit tricky, especially in the case
where the functions return something whose size is unknown at the point
of the call.

>The designer of the abstraction can even force users to always call one
>of these constructor functions, by giving the type an unknown
>discriminant part, thereby making it an "indefinite" type:
>
>   type Some_Value_Type (<>) is ... private; -- something non-limited
>
>This doesn't mean the actual completion of this type has to have a
>discriminant, but it does make uninitialized variables illegal:
>
>   Some_Value : Some_Value_Type; -- compiler error! indefinite type!
>
>This restriction is appropriate if the abstraction just doesn't include
>any notion of a "default" constructor.

Yes, I think this is a nice capability.

>(4) Since the constructor functions all return values of the access type
>and not the object type itself, these functions are _not_ primitive
>subprograms for the object type, so they will _not_ be inherited by
>derived types ("subclasses").  This is actually a good thing: It has
>frequently been argued that constructors should not be inheritable. (In
>fact, C++'s constructors aren't.)

In Ada, constructors (i.e. functions that are primitive-on-result) are
inherited, but become abstract, so you have to override them explicitly
(unless the derived type is abstract).  If you don't want to override
them, then return the class-wide type (or, as above, a pointer).

>(5) If a subclass can't just inherit a constructor, and the parent class
>doesn't include a default constructor, then the only way the subclass
>can properly implement a constructor of its own is if it somehow has
>access to the implementation details of its parent class. That pretty
>much forces you to put your subclasses into child packages.  Giving the
>base type an unknown discriminant also forces this, because it's illegal
>to derive a new type unless you can provide a constraint for the
>discriminant (or "see" that there really isn't one).

Umm, I don't think there is any such rule.  See 3.7(26).

- Bob