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,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!pt.cs.cmu.edu!sei!Goodenough
From: Goodenough@sei.cmu.edu
Newsgroups: comp.lang.ada
Subject: Re: Record rep specs for private components
Message-ID: <3560@fy.sei.cmu.edu>
Date: 23 Jun 89 19:57:56 GMT
References: <523@ajpo.sei.cmu.edu> <1635@petsd.UUCP>
Sender: jbg@sei.cmu.edu
In-reply-to: joe@petsd.UUCP's message of 20 Jun 89 13:06:12 GMT
List-Id: <comp.lang.ada>


In article Re: Record rep specs for private components of 20 Jun 89 13:06:12
GMT joe@petsd.UUCP (Joseph M. Orost) writes:

>According to AI-00551/02 (DRAFT):
>
>"If a component type is a private type, the size allowed in a component
>clause for the type is determined by applying the above rules to the full
>declaration of the private type."

AI-00551 is currently up to version 05, and is still under consideration by
the ARG.  AI-00550 briefly justifies why rep clause support is being required
for certain private types, namely, that if such clauses are not supported for
private types, the effect could be to discourage the use of private types,
since the decision to make a type private would then be equivalent to saying
that objects of the type never need to be positioned explicitly by component
clauses.  As a matter of language design, you don't want programmers to be
concerned about such effects when deciding whether to make a type private.
This would link privateness and rep clause issues in an undesirable way.

Ed Berard says that the underlying implementation of a private type should
not be known outside its parent package, and goes on to say:

"This means that it should be impossible for another program unit to specify
how much space an instance of this type should take up." 

But the point of a private type is not that its implementation is unknown --
it is that a program can't exploit that knowledge in unsafe ways.  To ensure
this, the language limits operations on objects of a private type to those
that are declared explicitly in the type's package.  The type's representation
is hidden in the sense that no representation-dependent operations are
visible.  This means, in general, that the logical properties of a program
are unchanged if the private type's representation is changed later.  Of
course, the effect of a program is similarly unchanged if a component clause
is given for a component having a private type, since the component clause
does not change the set of values allowed for the component, or the effect of
operations on the component.  So the ability to give a component clause is
quite consistent with the notion of a private type.

Of course, if a component clause is given for a private type and the private
type's full declaration is changed later, the component clause might no longer
be accepted (e.g., the component might require more space).  But such an
invalid component clause will be detected when the unit containing the rep
clause is recompiled, so there is no violation of safety.

In short, it would be a mistake to forbid the application of a component
clause to a component just because the component has a private type.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391