Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Shark8 <onewingedshark@gmail.com> writes:

> On Sunday, June 23, 2013 7:12:53 AM UTC-6, Robert A Duff wrote:
>> 
>> 
>> On the other hand, the private part kludge wouldn't be so bad if
>> the syntax were different:
>
> Perhaps something like this?

No, that's not at all what I meant.  I meant that a package would
come in three parts:

    package P is
        ...
    end P;

    package private P is -- Just making up syntax here.
        ...
    end P;

    package body P is
        ...
    end P;

Normally stored in 3 separate source files.  There would be no
private part syntax like we currently have.

I'm not suggesting this is the best idea -- I'm just suggesting
that it would fit in with the compilation model the Ada 83 designers
had in mind.  I would ditch that model, thus making the above
suggestion irrelevant.

> Package Example is
>    Type Opaque is private;
> private
>    Type Opaque is separate COMPLETE_NAME;
>    -- This flags to the compiler that the full type appears in the
>    -- package body (as COMPLETE_NAME) and the public 'Opaque' is
>    -- actually a pointer/reference/(not null access) to COMPLETE_NAME,
>    -- also any primitive ops for Opaque are transitively private ops 
>    -- of COMPLETE_NAME.
> end;

No, it's a bad idea to force the explicit use of pointer/heap when it's
not logically necessary.  C does that a lot.  Ada less, but it could
be even less.

>>  The private part should be a separate
>> syntactic compilation_unit, with its own with clauses, and should
>> normally be stored in a separate source file from the visible part.
>
> I don't know. Certainly for consistency's sake yes, but getting
> compiler writers to implement that as well might have been a
> death-knell for Ada 83.

My suggestion is trivial to implement.  And it wouldn't be "as well",
it would be "instead of".

>...Moreover, we would need some way to flag
> there isn't a PRIVATE area, like PRIVATE IS NULL; (Or conversely have
> the private section optionally in the spec, as it is now, but with
> PRIVATE IS SEPARATE as the trigger for an external private section.)

No, my suggestion is that there is NEVER a "private area", so there's
no need to indicate that there is none.

I'm not suggesting this as a change to Ada -- I'm suggesting that
it would have been a better way to design Ada 83.

>> There's an awful lot of horrible code duplication caused by the
>> fact that the private part is in the same file as the visible part.
>
> I'm not sure about that. Consider this:
> Type K;
>
> Type J is record
>  Item : K; -- might need to be access K.
> end record;
>
> Type K is new Integer Range 0..100;
>
> Sure "Type K" appears twice, but that's required so that we have some
> name for the type of J.Item. The items (full declarations) in the
> PRIVATE section are likewise.

Sorry, I wasn't clear.

That's not the duplication I'm talking about.  I'm talking about the
case where you have an abstraction with multiple implementations.
This happens often in the GNAT runtimes, for example.  Since the
private part is part of the implementation, you need multiple copies
of it for different platforms/environments.  Given Ada as it is,
that forces you to make multiple copies of the visible part,
which is a violation of the DRY principle.

- Bob