Re: Naming of Tagged Types and Associated Packages

["Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr>]

Very interesting, I think we are progressing...

Robert I. Eachus a �crit dans le message ...
>  A VERY simplified example:
>
>  with Ada.Finalization;
>  package People is
>
>    type Person is tagged private;
>
>    function Name(Who: in Person) return String;
>    procedure Set_Name(Who: in out Person; Name: in String);
>    function Address(Who: in Person) return String;
>    function Set_Address(Who: in out Person; Address: in String);
>    ...
>
>  private
>
>    package Add_Name is new Unbounded_String_Component(
>           Ada.Finalization.Controlled);
>    package Add_Address is new Unbounded_String_Component(
>           Add_Name.Record_Type);
>    type Person is new Add_Address.Record_Type with null;
>
>    pragma Inline(Name, Set_Name, Address, Set_Address);
>
>  end People;
>
>  Now in the body I'll have to write things like:
>
>    function Name(Who: in Person) return String is
>    begin return Add_Name.Get(Who); end Name;


Your example is excellent, because you declare a *private* tagged type, and
export its operations explicitely. But

pragma Disclaimer (on);
I do think, and often claim, that one of the big advantages of Ada over
other OO languages is that you can use inheritance at *implementation* level
without using it at specification level; or (like here) have hidden
inheritances, that allow you to break the transitive dependence. I have
therefore much sympathy for the way the example is written; however, we are
discussing naming of classes in the general case here, in the context of
"traditionnal" OO style.
pragma Disclaimer (off);

if you want to *visibly* add a facet, then it wouldn't work so easily (once
again, look at the example in the paper).

Why would you want to add visibly a facet ? Because this way, if you add new
operations to a facet, they are immediately inherited by all users. If you
instantiate privately, you'll have to add new "interface" routines to all
packages. Granted, this is better from the point of view of encapsulation,
but not from the point of view of flexibility. And the "pure OOP" approach
is most effective in cases where flexibility is considered more important
than encapsulation (but this is another debate).
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog