Re: Style: always declare subrountines?

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

porton@ex-code.com (Victor Porton) writes:

> 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) 

Far too restrictive. There are many times when it is good to implement
many small subprograms in the body, that simply do not belong in the
spec, public or private. Other children of the package should _not_
see them!

This is especially true when the body requires packages that the spec
does not. Moving subprogram declarations to the spec then requires
moving the package "with" clauses to the spec. This is sometimes
illegal, due to circularity or private children issues.

> 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.

If the public interface is not present, you'll get a compilation
error, not "wrong behavior".

Hmm, I guess you can get "wrong behavior" if you forgot to overload or
override a subprogram in the spec, and thus get the "parent"
subprogram. Is that what you are talking about? In that case, you can
sometimes make the parent procedure abstract

> Stylistic checkers for always declaring in package specification?

As others have said, there is no substitute for a good design process.

-- 
-- Stephe