Re: Re: Style: always declare subrountines?

Re: Re: Style: always declare subrountines?

[Grein, Christoph]

private with P.Implementation;     would do it. I do not remember the AI.
>   package P.Public is
>     type T is private;
>     ...
>   private
>     type T is
>       record
>         X : P.Implementation.Stuff;
>       end record;
>   end P.Public;
> 
> Unfortunately P.Implementation can't be a private package here. (I
> seem to remember someone saying that there was an AI that addressed
> this problem; can anyone point me at it if this is true?)

Style: always declare subrountines?

[Victor Porton]

How do you consider this:

If one would always declare every subrountine of a package body in the 
specification (in the public or in the private part) this excludes the
possibility that one may mistakedly create an internal subrountine with
the same specification as a not yet implemented public procedure and 
forget to implement this public procedure and so get wrong program
behavior.

Stylistic checkers for always declaring in package specification?

;Re: Style: always declare subrountines?

[Richard Riehle]

Victor Porton wrote:

> How do you consider this:
>
> If one would always declare every subrountine of a package body in the
> specification (in the public or in the private part) this excludes the
> possibility that one may mistakedly create an internal subrountine with
> the same specification as a not yet implemented public procedure and
> forget to implement this public procedure and so get wrong program
> behavior.

My own own preference for internal subprograms that have no
entry in the specification  to promote them to a private package
specification.   This promotes reuse, enhances maintenance, and
allows extensibility.   For example, consider:

            package P1 is
                procedure Q ...
                procedure R ...
                function    S   return ...
           end P1;

           package body P1 is
               function T ... return  ... is ... end T;
               function Z ... return  ... is ... end Z;
               function W ... return  ... is ... end W;
               procedure Q ... is ...   end Q;
               procedure R ... is ...   end R;
               function    S ... return ... is ...   end S;
          end P1;

The three functions, T, Z, and W can be promoted to a private package
specification,

            private package P1.Utilities is
               function T ... return  ... ;
               function Z ... return  ... ;
               function W ... return  ... ;
          end P1.Utilities;

Now package body for P1 is as before but,

          with P1.Utilities;
          package body P1 is  ... end P1;

For some reason, we continue to see some designers
miss out on the potential for decomposing their systems
so they can make the best use of private child library units.
The fundamental design policy can be stated as: only include
in package body the code corresponding directly to entries
in the specification.  Everything else should have its
own specification and implementation.

Richard Riehle

Re: Re: Style: always declare subrountines?

[John English]

Richard Riehle wrote:
> My own own preference for internal subprograms that have no
> entry in the specification  to promote them to a private package
> specification.   This promotes reuse, enhances maintenance, and
> allows extensibility.   For example, consider: [...snip...]

One thing that always bugs me is that private packages can only be
accessed from the body of a public package. What would be nice to
be able to do sometimes is:

  with P.Implementation;
  package P.Public is
    type T is private;
    ...
  private
    type T is
      record
        X : P.Implementation.Stuff;
      end record;
  end P.Public;

Unfortunately P.Implementation can't be a private package here. (I
seem to remember someone saying that there was an AI that addressed
this problem; can anyone point me at it if this is true?)

Another gripe: it would sometimes be nice to be able to say "type T
renames P.Implementation.Stuff", but the standard trick of using a
subtype to rename doesn't work because T is declared as a type, not
a subtype. Grrr!

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------