Re: Pre-Elaboration clarification.

["Mark Lundquist" <up.yerz@nospam.com>]

"Clueless" <chris@dont.spam.me> wrote in message
news:v59L7.42261$RI2.21722340@news2...
>
> Are there any basic rules of thumb that an "Intermediate" level
> programmer(as I was declared by my CS teacher) should follow in Ada as
> regards data types and spec files?

Yeah, here's one...

This is a "Beginner" mistake that as an "Intermediate" programmer you will
want to avoid :-).  I used to see it a lot from people who were no longer
beginners, but who somehow never "got it".

The Ada programmer learns that a package can have both a spec and a body,
and that only declarations can go in the spec, and only bodies can go in the
body, and bodies are the only things that can have statements.

As a result of this, sometimes a beginner gets the idea that "the spec is
the place for all my type definitions".  So they define types in the public
part of a spec that should be in defined in the body.  This goes
hand-in-hand with another beginner mistake, which is the failure to
understand and use private types.

Of course failure to encapsulate leads to fragile and buggy code, but it
also obscures intent.  Where things are declared (public, private, or body)
communicates important information to any reader trying to understand the
code.  A reader should always be able to apply the principle that if
such-and-such is visible at a given place, there is a "good reason" (related
to using the abstraction) for that visibility.

So the rule of thumb for type declarations in a package is:

- If only the body needs the type, then put it in the body.
- If code in other (non-child) packages depends on it, but only the compiler
(not the code) needs to know the representation, then put the full
definition in the private part.
- If the only things depending on the type are other types in the private
part, there is no need for a private_type_declaration (that is, "is private"
in the public part).  Define the type in the private part but don't mention
it in the public part.
- If the code in other (non-child) packages needs to see it, put it in the
public part of the spec

I wrote the cases in order from most- to least- encapsulated, because it's
good to get in the habit of thinking that way.

Have fun,
-- mark