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.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	T_FILL_THIS_FORM_SHORT autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c83a22003c320b45
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-11-04 05:44:12 PST
Newsgroups: comp.lang.ada
Path: 
 bga.com!news.sprintlink.net!pipex!uknet!dcs.gla.ac.uk!unix.brighton.ac.uk!je
From: je@unix.brighton.ac.uk (John English)
Subject: Re: Initialization Params for Controlled Types
Message-ID: <1994Nov4.134412.10010@unix.brighton.ac.uk>
Organization: University of Brighton, UK
X-Newsreader: TIN [version 1.2 PL2]
References: <CyBsE5.GFs@dit.upm.es> <CyC5I5.I93@inmet.camb.inmet.com>
Date: Fri, 4 Nov 1994 13:44:12 GMT
Date: 1994-11-04T13:44:12+00:00
List-Id: <comp.lang.ada>

Tucker Taft (stt@spock.camb.inmet.com) wrote:
: For a limited object, it is also generally reasonable
: to call an explicit initialization procedure with any number
: of parameters.  Again, the primary goal of Initialize is to
: provide *default* initialization.  Explicit parameterized 
: initialization can be performed in other ways (via functions
: or procedures).

There is one subtle danger with using procedures as "constructors".
Imagine the following:
  type BankAccount is tagged private;
  procedure Open (Account : in out BankAccount;
		  Name    : in String);

Here Open opens a bank account in a particular name.  Now if you
derive a new type CurrentAccount from BankAccount to produce a
BankAccount that allows overdrafts, you might have this:
  type CurrentAccount is new BankAccount with private;
  procedure Open (Account   : in out CurrentAccount;
		  Name      : in String;
		  Overdraft : in Money);

Here's where the danger is: the first procedure (Open for BankAccount)
is a primitive of BankAccount and will be inherited by CurrentAccount.
It's therefore possible to initialise a CurrentAccount as if it were
a BankAccount, which might leave the overdraft limit uninitialised:
  C : CurrentAccount;
  ...
  Open (C, "Fred Bloggs");  -- oops!

Okay, you can provide a default overdraft limit of 0.00, so this is
not an entirely convincing example; the point is that there is a
danger here which is non-obvious, since you might forget that there
is a second Open for CurrentAccounts which is provided due to inheritance.
C++ sidesteps this problem by making constructors non-inheritable.
The only way to accomplish this in 9X is to make sure that Open isn't
a primitive (e.g. by shoving it in a child package) which is fairly
painful.

-- 
-------------------------------------------------------------------------------
John English                    | Thoughts for the day:
Dept. of Computing              | - People who live in windowed environments
University of Brighton          |   shouldn't cast pointers
E-mail: je@brighton.ac.uk       | - In C++ only your friends can access your
Fax:    0273 642405             |   private parts
-------------------------------------------------------------------------------