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

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

Martin <martin@thedowies.com> writes:

> Secondly, I have to explain that using Ada "private" gives you "UML protected":

Not exactly.  Ada "private" means clients can't see it, but child
packages (which should be thought of as part of the same abstraction)
can.

It's a completely different visibility model than UML.  I don't see any
reason to be embarrassed about that.

> Option 2:
>    type T is tagged record
>       null;
>    private
>       F : Float;
>    end record;
>
>
> I prefer Option 2.
>
> Thoughts?

I don't think making Ada more like UML is a worthwhile goal.  If it
were, I'd prefer your option 1.  But I don't see the point:  In Ada,
packages are about visibility.  That's different from languages that
conflate the concept of "module" and "type" (which has both advantages
and disadvantages).  Overall, I prefer the Ada way.

If you want derived types to see their parent types components, you put
the derived types in a child package; if you don't, then you don't.
Attempts to mimic UML in Ada lead to a mess, as you've shown.

I share your disdain for what you called "opaque" types -- it forces you
into heap management, which leads to extra trouble.  But I object to
calling them "opaque" types.  Ada folks usually call them "stt access
types" and "stt incomplete types", or "Taft amendment types", because
they were invented by Tucker Taft and added to Ada 83 at the last minute
when nobody realized all the headaches they cause for compiler writers.
The term "opaque type" comes from Modula-2, IIRC, and is more like
an Ada private type, with some annoying restrictions added.

- Bob