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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,555956c1cdd22308
X-Google-Attributes: gid103376,public
From: Mats Weber <Mats.Weber@elca-matrix.ch>
Subject: Re: Help - Constructors - ASAP.
Date: 1998/08/03
Message-ID: <35C5CA85.85DDB431@elca-matrix.ch>#1/1
X-Deja-AN: 377494731
Content-Transfer-Encoding: 7bit
References: <6p75qi$rcj@news.latnet.lv> <m3lnpg7j5s.fsf@mheaney.ni.net>
 <6pi4jq$j73$1@nnrp1.dejanews.com> <EACHUS.98Jul30114523@spectre.mitre.org>
 <6pqdr2$hn2$1@nnrp1.dejanews.com> <35C1043E.9FFB23D0@elca-matrix.ch>
 <6psvnb$vkt$1@nnrp1.dejanews.com>
Content-Type: text/plain; charset=us-ascii
Organization: ELCA Matrix SA
Mime-Version: 1.0
Reply-To: Mats.Weber@elca-matrix.ch
Newsgroups: comp.lang.ada
Date: 1998-08-03T00:00:00+00:00
List-Id: <comp.lang.ada>

dennison@telepath.com wrote:

> I see. I thought you were somehow passing back an object of the right class
> for the context.

No, because you can't do this.

package Parent is

   type T is tagged private;

   function Construct return T'Class;
      -- Class-wide just to make it non-primitive.

end Parent;


with Parent;

package Child is

   type T is new Parent.T with private;

end Child;

As Parent has no knowledge of Child, its constructure cannot be modified to
return a Child.T. It will always return a Parent.T, which will raise
Constraint_Error in the following case:

declare
   X : Child.T := Parent.Construct;
begin
   ...

> But, a naieve reader would look at that and think that they could get back an
> object of *any* type in the class (as I have just proven :-) ), when in
> actuality they always get back the same class of object.

This means that you should not mess with tagged types as long as you are still
naive :-)

> If I read you correctly, what you were worried about was developers screwing
> up and forgetting to override the default constructors. Nothing about this
> solution prevents that. Now instead of getting the default constructor, our
> hapless client will compile with the class-wide constructor. They get an
> exception at runtime either way. But now the client, who is just as capable
> of screwing up as the subclass author, could goof and use the class-wide
> constructor on his own.

This seems to show that non-primitive _and_ non class-wide constructors are
preferable (e.g. using the nested package or child package approach).