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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jarthur!uunet!seas.gwu.edu!mfeldman
From: mfeldman@seas.gwu.edu (Michael Feldman)
Newsgroups: comp.lang.ada
Subject: Re: Pre-condition vs. Post-condition
Message-ID: <2947@sparko.gwu.edu>
Date: 28 Mar 91 02:54:26 GMT
References: <20600091@inmet> <23141@as0c.sei.cmu.edu> <2918@sparko.gwu.edu> <2929@sparko.gwu.edu> <5074@goanna.cs.rmit.oz.au> <jls.670109695@rutabaga>
Reply-To: mfeldman@seas.gwu.edu ()
Organization: The George Washington University, Washington D.C.
List-Id: <comp.lang.ada>

In article <jls.670109695@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
  ... much good stuff deleted
>
>That's not the issue: default initialization, particularly of private
>types, is for the benefit of the SUPPLIER, not the client.

Right. As long as the client program(mer) doesn't make hidden assumptions
in the client code about what the default value is.
>
>>One thing which would reduce this temptation would
>>be to set things up so that a type or subtype can be specified in
>>a package specification and its default value in the package body.
>
>Actually, this is a pretty good idea, at least for visible types
>(it doesn't matter for private types).

True, but see my comment above. This is probably no worse a problem than
arises with Ada private types in general, where the private part is visible
to the human even if it's hidden from the human's code.


Mike Feldman