comp.lang.ada
 help / color / mirror / Atom feed
From: Ken Garlington <GarlingtonKE@lmtas.lmco.com>
Subject: Re: Question about record rep spec placement
Date: 1997/01/17
Date: 1997-01-17T00:00:00+00:00	[thread overview]
Message-ID: <32E02DB1.6E06@lmtas.lmco.com> (raw)
In-Reply-To: E46D5J.EM3@world.std.com


Robert A Duff wrote:
> 
> parts.  However, because of the freezing rules, it is not always
> possible to do that.  Therefore, my style is to put the rep clause right
> after the type.  This makes various changes less painful -- e.g. suppose
> you want to add something into the visible part that freezes the type.
> You'll have to move the rep clause to do that.

I guess this depends upon whether being unable to put the rep spec in
the private area due to freezing rules is a "pathological" case (as has
been described previously) or will occur relatively often. If the
former,
then a comment should do for those cases where the rep spec can't be
placed in the private area. If the latter, then I think this potential
incompatibility from Ada83 to Ada should be more widely advertised.

I don't know which is the case; does anyone has real-world experience
they
could share?

> Besides, a style rule
> that says "Put this info in the private part when possible, but
> otherwise put it in the visible part" seems kludgy to me -- knowing that
> rule, I have no idea what it means that a rep clause is in the visible
> part.  Is it because clients are supposed to take advantage of it?  Or
> is it merely because there happens to be some freezing point of the
> type, and the programmer couldn't put the rep clause in the private
> part.

This was even more of a problem prior to the advent of child packages.
Was
something outside the private part because the client needed it, or
because
some support package needed it.

I think the style rule would be better stated as "If something is likely
to
change, or if the user should otherwise not depend on it, don't put it
in
the public part of the spec." (That's basically the way it's worded in
SPC
ADARTS, which we use.) Even if that rule can't always be followed,
I think it's still a good rule. Assuming Ada will let you follow that
rule
most of the time (and, at least in my Ada83 experience, it would), then
the exceptions should be relatively small and can be handled via
comments.
If you can't follow that rule most of the time, then "programming by
contract" isn't possible and we might as well all use Eiffel :)

> IMHO the freezing/forcing rules are a serious flaw in the language.
> 
> >  type T is {whatever};
> >  for type T use private;  -- Tell the user and compiler to look for
> >                           -- further specifics about T's representation
> >                           -- elsewhere in the package, perhaps even in
> >                           -- the package body.

"for type T use private"? Is that legal Ada? I've never used that
before!

I wouldn't say it as "Tell the user... to look for further specifics
about
T's representation elsewhere in the package." I would say "Tell the
user... if
he uses information gleaned outside the visible part of the package
spec,
he gets what he deserves." Basically, a higher-level abstraction of
"using
Unchecked_Conversion is both powerful and potentially dangerous."

BTW, I can think of some cases where a rep spec might be OK to make
public: A size
clause, perhaps, for packages supporting system programming, or a record
layout
that conforms to some stable standard (assuming you can write it
portably, or
know it won't be ported).

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com




  reply	other threads:[~1997-01-17  0:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-01-15  0:00 Question about record rep spec placement Ken Garlington
1997-01-15  0:00 ` Bob Gilbert
1997-01-16  0:00   ` Fergus Henderson
1997-01-17  0:00   ` Ken Garlington
1997-01-17  0:00     ` Bob Gilbert
1997-01-17  0:00       ` Robert A Duff
1997-01-17  0:00         ` Ken Garlington [this message]
1997-01-18  0:00           ` Robert A Duff
1997-01-18  0:00             ` Ken Garlington
1997-01-19  0:00               ` Robert A Duff
1997-01-21  0:00         ` Bob Gilbert
1997-01-22  0:00           ` Ken Garlington
1997-01-23  0:00             ` Art Schwarz
1997-01-25  0:00               ` Ken Garlington
1997-01-24  0:00             ` Bob Gilbert
1997-01-25  0:00               ` Ken Garlington
1997-01-20  0:00       ` Ken Garlington
1997-01-15  0:00 ` Norman H. Cohen
1997-01-16  0:00   ` Ken Garlington
1997-01-17  0:00     ` Robert A Duff
1997-01-18  0:00       ` Ken Garlington
1997-01-16  0:00 ` Jeff Creem
1997-01-16  0:00 ` Jerome Desquilbet
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox