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

[Niklas Holsti <nobody@nowhere.fi>]

Anonymous Coward wrote:
>>The whole point of private types is that the only visible operations
>>on them are assignment, equality and inequality, and any explicitly
>>defined operations in the visible part of the package
>>specification. 
> 
> 
> That makes sense.  As a default, it probably would be a poor language
> design to have private types automatically export public primitive
> operations.  If I created an Altitude_Type, I wouldn't want to inherit
> the "+" operation.

The following is perhaps not quite on the original topic, but this 
thread reminds me of an idea for a new feature related to private 
types that I would like to present.

My Ada packages often define types that are *mostly* private in 
the sense that I only want the clients to use a restricted set of 
operations and properties of the type. However, I often do not 
make these types actual private types because I want to reveal 
some properties, such as discreteness, that I cannot now specify 
for a private type.

I would like to be able to reveal some properties of private types 
in the same way as we can now define generic formal types, for 
example saying that the type is discrete (type T is (<>)) or is a 
modular type (type T is mod <>). So I would like to write, for 
example, a package like this:

    package P is

       type Element is private (<>);
       -- This is not Ada. The intended meaning is that type
       -- Element is private, but is a discrete type.

       -- Some operations using Element.

    private

       type Element is (This, That, The_Other);
       -- See, Element is really a discrete type.

    end P;

Other (client) packages can then use the fact that P.Element is a 
discrete type, for example by using P.Element as an index type:

    with P;

    package Client is

       type Set is array (P.Element) of Boolean;
       ...
    end Client;

However, the whole definition of P.Element would still be hidden, 
so clients could not refer for example to P.Element'(P.This).

There would be a pleasing symmetry in this new feature if the 
properties that could be revealed about a private type would match 
exactly the properties that can now be defined for a generic 
formal type. A private type with some properties revealed in this 
way could then be used as the actual type to instantiate a generic 
with a formal type that has matching properties.

There are even some places in the Ada LRM where the proposed 
feature would be useful. For example, the LRM (95) now defines, in 
13.7.1:

    package System.Storage_Elements is
       ...
       type Storage_Offset is range "implementation defined";
       ...
       type Storage_Element is mod "implementation defined";
       ...
    end System.Storage_Elements;

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?

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