Re: Record rep specs for private components

[eberard@ajpo.sei.cmu.edu (Edward Berard)]

In article <3560@fy.sei.cmu.edu>, Goodenough@sei.cmu.edu writes:
> 
> 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.
> 

I am strongly in favor of private types. Indeed, it is through the
information hiding provided by private types that module (and object)
coupling is reduced. I also understand the need for "rep specs."
However, the purpose of rep specs often seems at odds with the
purpose of private types, i.e., the very purpose of rep specs is to
explicitly define the underlying implementations.

> 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

[Before I begin the next discussion, I will admit that there are a few
issues that I do not about. For example, is rep spec support required
for all private types? Is rep spec support required for limited
private types? Is rep spec support limited to scalar private types,
i.e., it is not allowed for composite private types? What about
(limited) private types with discriminants, or private types
implemented using records with variant parts?]

Simply put, I would prefer that private types be very black boxes.
John Goodenough, and others, suggest that there is some benefit to
making some aspects of a private type visible outside of the program
unit in which it is declared, i.e., a "slightly gray" black box. While
I understand the point (and the usefulness), I think the current
situation has two undesirable drawbacks:

	1. A software engineer who is specifying a record layout using
	   both rep specs and private types must refer to the original
	   private type declaration when allowing space for the
	   private type. This requires both time to find the original
	   component, and possibly several tries at allocating the
	   correct amount of space (remember, the private type can be
	   more complex than a simple integer). The software engineer
	   may even allow more space than is necessary.

	2. If the software engineer is required to allow for a large
	   amount of space originally, and a change to the underlying
	   implementation of the private type greatly reduces
	   necessary space, the compiler may not notify the software
	   engineer that less space is needed. If the software
	   engineer is trying to optimize space, this may prove
	   costly.

I propose (what I feel) is a possible solution: size attributes for
private types which can be used in component clauses. One, or more,
attributes could be used to calculate the minimum amount of space
required. This would decrease the need to refer to the program unit in
which the private type was originally declared, and allow the compiler
to allocate the necessary space (provided that the software engineer
made correct use of the attributes).

If these attributes are already in Ada, then no languages changes are
needed. If not, could such attributes be candidates for Ada 9X?

				-- Ed Berard
				   Berard Software Engineering, Inc.
				   18620 Mateney Road
				   Germantown, Maryland 20874
				   Phone: (301) 353-9652