Re: packages and private parts

Re: packages and private parts

[Norman H. Cohen]

Robert Dewar wrote:

> Well it is no surprise that Norman disagrees, he argued strongly during
> the design, but unpersuasively (i.e. not enough people were persauaded),
> that parent units should be allowed to have declarations limiting what
> children they permit.

Actually, what I argued during the design was not that parent units
should be able to declare themselves childless, but that parent units
should be able to stipulate that certain declarations are hidden even
from children.  (We had already bought the new reserved word "protected"
for use in protected objects, and we could easily have amortized its
cost by allowing a package to have both a protected part visible to
children and a private part hidden from children.)

Robert is right that I was unable to persuade enough people (i.e., a set
of people that included Tucker Taft :-) ) of this position, although
concern about this issue was widespread.  My ally in this argument,
David Pogge, was unable to carry the day even with his colorful warnings
about the "Howard Hughes effect"--total strangers declaring themselves
to be your children.  Indeed, Tucker eventually won me over me with his
argument that adding a child to a package should be viewed as the moral
equivalent of modifying the text of the package.

Long after consensus had been achieved that child packages, with their
associated visibility rules, would be a part of Ada 95, I realized that
a far more serious concern than the Howard Hughes effect was the way in
which child visibility into private declarations of the parent muddied
the contractual interface of a library package, restricting the freedom
of the package's author to change the implementation of a private type
in a later version of a fielded package.  (I discussed this concern in
more detail in another post yesterday.)  I wish this argument had
occurred to me earlier.

--
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: packages and private parts

[Robert Dewar]

<<Robert is right that I was unable to persuade enough people (i.e., a set
of people that included Tucker Taft :-) ) of this position, although
concern about this issue was widespread.  My ally in this argument,
David Pogge, was unable to carry the day even with his colorful warnings
about the "Howard Hughes effect"--total strangers declaring themselves
to be your children.  Indeed, Tucker eventually won me over me with his
argument that adding a child to a package should be viewed as the moral
equivalent of modifying the text of the package.
>>

I know there is a smiley there, but still, I think this should not go
unanswered. My memory was that VERY few people were convinced, I certainly
was not, I thought the suggestion of absolute privacy was a serious mistake,
and i still do, and that is the same view that a majority of people had!

<<Long after consensus had been achieved that child packages, with their
associated visibility rules, would be a part of Ada 95, I realized that
a far more serious concern than the Howard Hughes effect was the way in
which child visibility into private declarations of the parent muddied
the contractual interface of a library package, restricting the freedom
of the package's author to change the implementation of a private type
in a later version of a fielded package.  (I discussed this concern in
more detail in another post yesterday.)  I wish this argument had
occurred to me earlier.
>>

Well that argument was made clearly, if not by you, then by others, and
was still not convincing.

I repeat my earlier suggestion. I think this concern is a straw man. I
certainly have not seen any problems arising in real application programs
from this concern, has anyone else? I am not talking about cases you
can construct in your mind, I am talking about real cases from real
applications!

Certainly it would be perectly fine to add a pragma restricting visibility
in the manner Norman suggests, but this issue has never come up among the
thousands of people actually using Ada 95, so it seems to me this is a
case where the majority and Tuck and the RM all agree, and it's a good
thing that they do!

Re: packages and private parts

[Norman H. Cohen]

Speaking of concerns that child visibility into private parts of parent
packages could be harmful, Robert Dewar wrote:

> My memory was that VERY few people were convinced, I certainly
> was not, I thought the suggestion of absolute privacy was a serious mistake,
> and i still do, and that is the same view that a majority of people had!

For the record, my memory is quite different.  I recall that, at least
early in the Mapping Phase of the Ada 9X project, many of the
reviewers--including Robert--were seriously concerned about this issue. 
Tucker had to fight hard to defend the rule, but did so skillfully and
eventually won most of us over, including me.  It is not unheard of for
Robert to forcefully argue different sides of an issue on different
occasions, but I suspect that Robert is remembering of a later stage of
the Ada 9X project than I am.

> Certainly it would be perectly fine to add a pragma restricting visibility
> in the manner Norman suggests, but this issue has never come up among the
> thousands of people actually using Ada 95, so it seems to me this is a
> case where the majority and Tuck and the RM all agree, and it's a good
> thing that they do!

Let me clarify that "in the manner Norman suggests" is meant to modify
"restricting visibility", not "pragma".  I do not agree that it would be
"perfectly fine" for an implementation to add a restriction making a
unit that is legal according to the standard illegal for a particular
implementation, except in the absence of an implementation-defined
pragma.  

On the other hand, there is nothing wrong with an implemenation-defined
pragma

   pragma Subject_To_Change ( entity-name );

to flag entities declared in the private part of a package, so that a
compiler would generate a WARNING if the named entity were later
referrerd to in the private part of a child.  When Robert says that
"this issue has never come up among the thousands of people actually
using Ada 95", he really means that ACT has not received a request for
such a pragma.  Not much can be inferred from that fact, except perhaps
that the usefulness of such a pragma has not been widely discussed until
now.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: packages and private parts

[Robert Dewar]

Norman said

<<For the record, my memory is quite different.  I recall that, at least
early in the Mapping Phase of the Ada 9X project, many of the
reviewers--including Robert--were seriously concerned about this issue.>>

Your memory certainly bares no relation to what my position was. If you
remember I was the one arguing for a much more general capability
(with private) that would have been even more unacceptable from your
point of view, because it would have allowed *any* unit to get at
the private part of any other unit without permission!

Re: packages and private parts

[Tucker Taft]

Jeff Carter (carter@innocon.com) wrote:

: Norman H. Cohen wrote:
: > 
: > I strongly disagree.  One of the great strengths of child units is
: > precisely that you can use them to, in effect, extend packages in ways
: > that the original author did not anticipate.  This is precisely what

: This is the big problem with child packages. To correct the non-existent
: problem of subsystems, the language now allows anybody to create a child
: of any (non-language-defined) package, with full visibility of a private
: type's internal structure, in a way which is difficult if not impossible
: to detect. So after all the hard work by a "great designer" to design a
: safe, robust package, someone who is not so great can hack a child and
: mess with the internals, destroying the safety and robustness.

A child package is only included in a program if you mention it in
a "with" clause.  So don't "with" a child package you don't trust.
Just the existence of a child package doesn't destroy anything.

It is best to think of child packages as an abstraction structuring 
mechanism.  You (or the "hacker") could choose of course to just 
edit (or rewrite) the original package, making it bigger and bigger, and 
forcing massive recompilations every time you do so.  Alternatively, you 
can structure your abstraction as a (potentially growing) set of child 
packages, reducing the effect of any particular change to those clients 
dependent on the child being changed.

In my view, the point of encapsulation and information hiding is
not really to "hide" something, or to prevent it from being 
changed (or "destroyed' ;-).  Rather it is to make it easier to find all
code that depends on a particular implementation choice, so that 
when the implementation is inevitably changed, you can track down all the
potentially affected code and fix it as necessary.

In Ada 95, all such code is restricted to a single "subsystem,"
rooted at the package containing the private declaration.  
The child packages of a subsystem can be used to provide additional 
operations on a private type that were not anticipated when the original
package was defined, or that are needed by only a subset of the clients.  
The alternative of making the type non-private is clearly worse, as is 
bloating up the original package with operations that only a subset 
of the clients would ever need.

The C++ and Java equivalent to Ada's private declarations are roughly 
the "protected" declarations (C++/Java "private" is analogous to 
"package body" declarations).  However, the protected declarations are
visible to all subclasses, no matter where they are or who "owns" them.
If a protected declaration is changed, an unbounded amount of code
may need changing, and much of it might not be owned by or available to the 
team in charge of the original class.

With Ada 95, presuming you establish "owners" on the basis of subsystems
(which seem wise), then since all the code that might be affected by a change
is part of the same subsystem, it can be found and fixed relatively easily
and with minimal cross-organization traumas.

If you get the original package from a third party, then you might
still want to extend it in some way.  If you do that, then you would
want to establish a local "owner" of the subsystem rooted at
the original third-party package, and that local owner would be responsible
for all children added by your organization, and would be responsible for 
updating them when your organization received a new version from the
third party.

By the way, I don't recommend putting all type extensions of a tagged type
in children of the package defining the type.  Children should be used 
primarily for exporting additional operations of the abstraction rooted at 
their parent.  If to write certain type extensions you need some additional 
operations on the parent type, then define those additional operations in a 
child package.  The type extensions can "with" that child package to 
accomplish their job.  Of course some type extensions are really part 
of the same abstraction as the parent type, and those make perfect sense 
to be in a child package.

: Jeff Carter
: Innovative Concepts, Inc.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: packages and private parts

[Ken Garlington]

Tucker Taft wrote:
> 
> In my view, the point of encapsulation and information hiding is
> not really to "hide" something, or to prevent it from being
> changed (or "destroyed' ;-).  Rather it is to make it easier to find all
> code that depends on a particular implementation choice, so that
> when the implementation is inevitably changed, you can track down all the
> potentially affected code and fix it as necessary.

This is also a primary motivation for the use of encapsulation/IH in the
Software Productivity Consortium's ADARTS methodology, which we've used
with some success. 

Based on my limited Ada 95 experience to date, I've
found that child packages support system integrity, not threaten it.

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

Re: packages and private parts

[Jeff Carter]

Robert Dewar wrote:
> As for the "destroying safety and robustness issue", I think this is
> totally bogus.
> 
> The safety and robustness of a system depends on the integrity of
> the sources. If anyone can go changing sources then of course any
> guarantees on private part integrity are destroyed, and furthermore
> the user of the package has potentially no knowledge that it has
> been destroyed in this way. Clearly this is swomething that CM
> systems must protect against.

Except, of course, that anyone can write a child without changing
sources, but with the same effect. Putting the sources under CM doesn't
prevent this.

> Child packages are much safer. If you have a set of packages from
> a "great designer", and want to use them, then use them, do NOT
> use any suspicious non-official children! Remember that a program
> is only affected by the presence of child packages if it directly
> or indirectly with's these children.

How do you know which children are official and which are not? How do
you know whether a programmer has written and used an unauthorized child
that is not known to the rest of the system?

> Remember also that the integrity of private parts is always
> attackable using unchecked convrsion. You expect to be able to
> defend against this with rules that limit the use of UC, so put
> into palce appropriate rules that limit the use of child packages
> if you are concerned about this problem, and possibly enforce
> them with your CM package, if this is useful.

Unchecked_Conversion and overlays using an address clause are easy to
detect. Child packages are very difficult to detect.
-- 
Jeff Carter
Innovative Concepts, Inc.

Now go away, or I shall taunt you a second time.

Re: packages and private parts

[Larry Kilgallen]

In article <32FF4D8D.167EB0E7@innocon.com>, Jeff Carter <carter@innocon.com> writes:
> Robert Dewar wrote:

>> Child packages are much safer. If you have a set of packages from
>> a "great designer", and want to use them, then use them, do NOT
>> use any suspicious non-official children! Remember that a program
>> is only affected by the presence of child packages if it directly
>> or indirectly with's these children.
> 
> How do you know which children are official and which are not? How do
> you know whether a programmer has written and used an unauthorized child
> that is not known to the rest of the system?

You know all of this by whether the child has been entered into the
configuration manager. This is really no different than how you know
whether a particular copy of the parent is official.

For "the configuration manager" you are free to use any method your
organization feels is safe, ranging from a diskette set as write-lock
(or not) up to digital signatures on the sources.

While a programmer might be able to write an unauthorized child
package, she cannot put it into the configuration management
system without following the rules for the particular local
environment.  Those rules might extend from "free-for-all" up
to measuring against coding standards which require some extra
approval for child packages.

Larry Kilgallen

Re: packages and private parts

[Robert Dewar]

Jeff Carter says

<<Except, of course, that anyone can write a child without changing
sources, but with the same effect. Putting the sources under CM doesn't
prevent this.>>

  It should, this is clearly something any CM system for Ada should
  provide (complete trackability of who writes what).

<<How do you know which children are official and which are not? How do
you know whether a programmer has written and used an unauthorized child
that is not known to the rest of the system?>>

  If your CM system cannot control the set of sources you are dealing
  with it is inadequate to the task.

<<Unchecked_Conversion and overlays using an address clause are easy to
detect. Child packages are very difficult to detect.>>

  This seems completely incomprehensible, child units are perfectly easy
  to "detect", you cannot use them without an explicit with statement!

Re: packages and private parts

[Jon S Anthony]

In article <dewar.855349349@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> I repeat my earlier suggestion. I think this concern is a straw man. I
> certainly have not seen any problems arising in real application programs
> from this concern, has anyone else? I am not talking about cases you
> can construct in your mind, I am talking about real cases from real
> applications!

I agree.  What's more,


> Certainly it would be perectly fine to add a pragma restricting visibility
> in the manner Norman suggests, but this issue has never come up among the

this seems superfluous and a waste.  If you want something not merely
private but _damn_ private, then put it in the _body_ - that's one of
the reasons its there.  Or use the subpackage trick (which, in the end
has it in the body anyway).  I don't see the problem.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: packages and private parts

[Mats Weber]

> >Unfortunately, the price for this is an annoying restriction (RM
> >10.1.1(16)) against declaring an ordinary package as a child of a
> >generic-package instance.
> 
> Why do you consider that restriction "annoying"?  I can't remember ever
> wanting to violate it...

The annoying thing with this kind of restriction is that you really
don't know why it is there when you read the non-annotated RM. Does the
anotated RM say anything about this particular one ?

Re: packages and private parts

[Mats Weber]

> >Unfortunately, the price for this is an annoying restriction (RM
> >10.1.1(16)) against declaring an ordinary package as a child of a
> >generic-package instance.
> 
> Why do you consider that restriction "annoying"?  I can't remember ever
> wanting to violate it...

I consider it annoying because if I write a child P.C of some package P,
and the author of P later decides that his package should be generalized
and creates Generic_P, replacing the original P with

   package P is new Generic_P(...);

then my child package P.C becomes illegal. And that is bad because to
make it legal, I have to make it a generic child of Generic_P and thus
do the same generalization as was done for P, which I may not always be
able to do.

Re: packages and private parts

[Norman H. Cohen]

Robert A Duff wrote:

> >Unfortunately, the price for this is an annoying restriction (RM
> >10.1.1(16)) against declaring an ordinary package as a child of a
> >generic-package instance.
> 
> Why do you consider that restriction "annoying"?  I can't remember ever
> wanting to violate it...

It's annoying because it outlaws innocent and natural combinations of
what ought to be orthogonal language features.  It's quite reasonable
for a programmer to write something like

   package Dice is
      pragma Pure;
      subtype Die_Value is
         Integer range 1 .. 6;
   end Dice;

   with Dice;
   with Ada.Numerics.Discrete_Random;
   package Random_Dice is
      new Ada.Numerics.Discrete_Random
         ( Dice.Die_Value );

   package Random_Dice.Pair_Of_Dice is  -- ILLEGAL!
      subtype Pair_Value is
         Integer range 
            2*Die_Value'First .. 2* Die_Value'Last;
      function Random_Pair
        (Gen: Generator) return Pair_Value;
   end Random_Dice.Pair_Of_Dice;

Of course there are ways to program around this forbidden construct, but
why should I have to?  Yes, I know, the rule prohibiting Random_Dice
from having noninstance children ensures that a package whose name is
not of the form Ada.Numerics.Discrete_Random.* does not have visibility
into the private part of instances of Ada.Numerics.Discrete_Random.  But
that's a rather obscure consideration, of interest primarily to us
language lawyers, and probably the farthest thing from the mind of the
programmer who writes the code above and finds that it won't compile.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: packages and private parts

[Tucker Taft]

Norman H. Cohen (ncohen@watson.ibm.com) wrote:
: ... Yes, I know, the rule prohibiting Random_Dice
: from having noninstance children ensures that a package whose name is
: not of the form Ada.Numerics.Discrete_Random.* does not have visibility
: into the private part of instances of Ada.Numerics.Discrete_Random.  But
: that's a rather obscure consideration, of interest primarily to us
: language lawyers, and probably the farthest thing from the mind of the
: programmer who writes the code above and finds that it won't compile.

The fact that only code in the subsystem "Ada.Numerics.Discrete_Random.*"
has visibility of the private declarations of Ada.Numerics.Discrete_Random
is essential to the child package concept.  It means that when
you alter the private declarations, you can have confidence that only
code in this subsystem needs to be examined.  To me, the whole point
of information hiding/encapsulation is to be able to find easily all of the
code that may need to be fixed when an implementation detail is changed.

If you allow child packages of any instantiation to have such visibility,
then you have a potentially unbounded amount of code to find and fix, much
of which will not be available to the maintainers of the generic subsystem.

: Norman H. Cohen
: mailto:ncohen@watson.ibm.com
: http://www.research.ibm.com/people/n/ncohen

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: packages and private parts

[Norman H. Cohen]

Tucker Taft wrote:
> 
> The fact that only code in the subsystem "Ada.Numerics.Discrete_Random.*"
> has visibility of the private declarations of Ada.Numerics.Discrete_Random
> is essential to the child package concept.  It means that when
> you alter the private declarations, you can have confidence that only
> code in this subsystem needs to be examined.  To me, the whole point
> of information hiding/encapsulation is to be able to find easily all of the
> code that may need to be fixed when an implementation detail is changed.
> 
> If you allow child packages of any instantiation to have such visibility,
> then you have a potentially unbounded amount of code to find and fix, much
> of which will not be available to the maintainers of the generic subsystem.

Oh, I quite agree that, given visibility into the private parts of
ancestor packages, the restriction against instances having ordinary
children is necessary.  I was just answering Bob Duff's question about
why I consider the restriction annoying.

(In programming, as in life, I recognize that many things that I find
annoying are necessary.)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen