Re: Child packages

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <1994Oct18.103131@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:

 > It is sort of like a rail at the edge of a cliff to keep people
 > from falling off. Something simple is sufficient but if you want
 > to worry about all the really stupid people then maybe you should
 > put up a 12 foot high barier in plexiglass or something. I think
 > that would really enhance places like the Grand Canyon. :-)

   I don't think we disagree.  I think a simple railing is sufficient,
although a low stone wall may be more aesthetically pleasing.  As I
said, originally I was opposed to illegitimate children, but in the
current design, they are a net win.

   But I do think that the packages that are like scenic lookouts on
cliff edges do need the railings.  For example, if a creation function
does more than just create objects, then a note in the private part to
that effect may avoid a few missteps.  A horrible but perfectly
natural example would be a package with a private type which is a
pointer to a record type declared in the private part.  In the
implementation the create operation would do the needed locking, and
the initial value operations on the hidden type count on the locking
having been done.  A one line comment in the hidden object type can
save a lot of grief.  (The alternative is to put the hidden type in
the pacakge body.  That is why such a package is the programming
equivalent of an attractive nuisance.)




--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...