Re: Re-exporting primitive operations of a private type (like "-", and 'min)

[Niklas Holsti <nobody@nowhere.fi>]

Jean-Pierre Rosen wrote:
> Niklas Holsti a �crit :
> 
>> With the new feature, the "implementation defined" pseudocode could be 
>> replaced by real code:
>>
>>       type Storage_Offset is private range <>;  -- Not Ada.
>>       type Storage_Element is private mod <>;   -- Not Ada.
>>
>> The full type declarations would be in the private part of the 
>> package, as usual.
>>
>> In such declarations, the "private" keyword is perhaps unnecessary, 
>> since the presence of the box "<>" shows that the declared type is 
>> partly hidden.
>>
>> Does this idea appeal to anyone?
>>
> I fail to see the benefit. The only thing that would be "hidden" with 
> such a declaration is the actual value of the bounds. But you could get 
> them with 'First and 'Last. So, there would be no benefit in pretending 
> that they are "private".

I think there would be a benefit -- it would *force* the clients 
of this package to use 'First and 'Last, instead of other *not 
standardized* items, for example some named numbers that may be 
defined in a particular implementation of this package.

But I agree that the advantage in this example is small. Let me 
explain the context more clearly.

You have an Ada program that contains a package A which defines a 
type A.T, and a package B that uses A.T in some way. For some 
reason (say, different platforms or different product variants) 
you have several variants of package A, say A', A" and so on. They 
all have the Ada name A, but they exist in different source 
directories, for example. To build a particular version of this 
program, you select a variant of A and compile it together with B. 
The variants define the type A.T in different ways; A' may define 
it as an enumeration, A" as an integer type, etc.

You want the same package B to be compatible with all variants of 
package A, even though the different variants of type A.T differ 
in detail. Thus, there must be some form of contract or 
specification that every variant of type A.T must satisfy and 
which defines how package B can use type A.T.

The only way to express such a contract in Ada, now, is to define 
A.T as (fully) private and provide the necessary operations in 
package A. But this means that A.T cannot be (visibly) discrete, 
so it cannot be used as an array index, cannot be used as a 
discriminant, and cannot be an actual type in generic 
instantiations where the formal type is more specific than "private".

An alternative would be to make package B generic, with a generic 
formal type standing for A.T, and then instantiate B with whatever 
variant of A.T is at hand. The definition of the generic 
parameters of B then define the contract. However, this method is 
not very practical when there are many packages (B, C, D, ... ZZ) 
that depend on A.T, and perhaps on other packages with variants. 
Moreover, it seems like overkill when you know that there will be 
only a single instantiation of B (and C, D, ... ZZ) in any version 
of the program.

The contract aspect of Ada generics is a good thing, but it is 
one-sided: it only lets the generic unit specify what it *expects* 
of a type that it will be given; there is now no similar way to 
specify what a unit *promises* of a type that it *provides*. One 
can only define a public type, which usually overspecifies the 
contract, or a (fully) private type, which has limitations as I 
said above.

My proposal aims for a similar contract aspect for private types, 
to let the provider of a type specify the type's properties 
without forcing "the rest of the world" to be defined as generic 
and parametrized with this type.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .