Private Children

Private Children

[Matthew Heaney]

Can a public child package with its private sibling?

According to my compiler, the answer is no.  When I try to compile the
unit below (P.C2), I get the following error message:

gcc -c -gnatc /home/matt/p-c2.ads
p-c2.ads:1:06: current unit must also be private descendant of "P"


Public child P.C2 only uses the entity provided by its private sibling
P.C1 in its private region.  What is the rationale for making this
illegal?



--STX
package P is

   pragma Pure;

end P;


private package P.C1 is

  I1 : Integer;

end P.C1;


with P.C1;
package P.C2 is

  I2 : Integer;

private

  I3 : Integer := P.C1.I1;

end P.C2;

Re: Private Children

[Ted Dennison]

In article <m3bteacxb8.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Can a public child package with its private sibling?
>

Almost exactly one month ago, I posted the exact same question.
Go to deja.com and search for a thread titled "Children of private
compilation units" to see the discussion.

As I remember, it went something like this: Gnat doesn't accept it, and
Robert Dewar says its not legal Ada. ObjectAda and GreenHills do accept
it, and Tucker Taft says it *is* legal Ada. I offered to send in a bug
report to the appropriate vendor, if a consensus could be reached on
which one was in error. Currenly there appears to be no such consensus.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Private Children

[Tucker Taft]

Ted Dennison wrote:
> 
> In article <m3bteacxb8.fsf@mheaney.ni.net>,
>   Matthew Heaney <matthew_heaney@acm.org> wrote:
> > Can a public child package with its private sibling?
> >
> 
> Almost exactly one month ago, I posted the exact same question.
> Go to deja.com and search for a thread titled "Children of private
> compilation units" to see the discussion.
> 
> As I remember, it went something like this: Gnat doesn't accept it, and
> Robert Dewar says its not legal Ada. ObjectAda and GreenHills do accept
> it, and Tucker Taft says it *is* legal Ada. I offered to send in a bug
> report to the appropriate vendor, if a consensus could be reached on
> which one was in error. Currenly there appears to be no such consensus.

No, this was a different issue.  It had to do with whether
a specless subprogram was considered a spec or a body.  Bodies
are allowed to "with" private siblings, specs are not.  In this
case, the ultimate consensus position, based on AARM readings,
is that a specless subprogram is treated like a "spec" for the
purposes of this rule, and may not "with" a private sibling.

To answer the question posed by this new question, the answer
given by Dale was correct, that private children provide "compilation
privacy."  If you want to allow something to be "with"ed by public
children's specs, but contain content that is only visible to
the private part of the child's spec, the following idiom works:

   package Mostly_Private is
   private
       ... -- Declarations visible only in private part of other public
       ...  -- siblings
   end Mostly_Private;

That is, put the entire set of declarations in the private part
of a public child.


> T.E.D.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Private Children

[Matthew Heaney]

On 21 Jun 1999 17:04, Tucker Taft <stt@averstar.com> wrote:

> To answer the question posed by this new question, the answer
> given by Dale was correct, that private children provide "compilation
> privacy."  If you want to allow something to be "with"ed by public
> children's specs, but contain content that is only visible to
> the private part of the child's spec, the following idiom works:
> 
>    package Mostly_Private is
>    private
>        ... -- Declarations visible only in private part of other public
>        ...  -- siblings
>    end Mostly_Private;
> 
> That is, put the entire set of declarations in the private part
> of a public child.

I did what I think you wanted me to do, but got this error message:

gcc -c -gnatc /home/matt/p-c2.ads
p-c2.ads:9:23: "I1" is not a visible entity of "C1"


Is this a compiler bug, or did I misunderstand what you said?

Can a package really see the private part of its sibling?  I thought
that only your own children could see your private part.

Or did you mean for me to put I1 in the private part of P, not P.C1?


--STX
package P is

   pragma Pure;

end P;


package P.C1 is
private

  I1 : Integer;

end P.C1;


with P.C1;
package P.C2 is

  I2 : Integer;

private

  I3 : Integer := P.C1.I1;

end P.C2;

Re: Private Children

[Matthew Heaney]

On 21 Jun 1999 17:04, Tucker Taft <stt@averstar.com> wrote:

> To answer the question posed by this new question, the answer
> given by Dale was correct, that private children provide "compilation
> privacy."  If you want to allow something to be "with"ed by public
> children's specs, but contain content that is only visible to
> the private part of the child's spec, the following idiom works:
> 
>    package Mostly_Private is
>    private
>        ... -- Declarations visible only in private part of other public
>        ...  -- siblings
>    end Mostly_Private;
> 
> That is, put the entire set of declarations in the private part
> of a public child.

I did what I think you wanted me to do, but got this error message:

gcc -c -gnatc /home/matt/p-c2.ads
p-c2.ads:9:23: "I1" is not a visible entity of "C1"


Is this a compiler bug, or did I misunderstand what you said?

Can a package really see the private part of its sibling?  I thought
that only your own children could see your private part.

Or did you mean for me to put I1 in the private part of P, not P.C1?


--STX
package P is

   pragma Pure;

end P;


package P.C1 is
private

  I1 : Integer;

end P.C1;


with P.C1;
package P.C2 is

  I2 : Integer;

private

  I3 : Integer := P.C1.I1;

end P.C2;

Re: Private Children

[Tucker Taft]

Matthew Heaney wrote:
> 
> On 21 Jun 1999 17:04, Tucker Taft <stt@averstar.com> wrote:
> 
> > To answer the question posed by this new question, the answer
> > given by Dale was correct, that private children provide "compilation
> > privacy."  If you want to allow something to be "with"ed by public
> > children's specs, but contain content that is only visible to
> > the private part of the child's spec, the following idiom works:
> >
> >    package Mostly_Private is
> >    private
> >        ... -- Declarations visible only in private part of other public
> >        ...  -- siblings
> >    end Mostly_Private;
> >
> > That is, put the entire set of declarations in the private part
> > of a public child.
> 
> I did what I think you wanted me to do, but got this error message:
> 
> gcc -c -gnatc /home/matt/p-c2.ads
> p-c2.ads:9:23: "I1" is not a visible entity of "C1"
> 
> Is this a compiler bug, or did I misunderstand what you said?
> 
> Can a package really see the private part of its sibling?  I thought
> that only your own children could see your private part.

Oops, right you are.  The "idiom" I was misremembering was actually to
create an extra level in the hierarchy, with all of the public
children made into public children of this intermediate level,
with the intermediate level spec having only a private part.
You could then use library unit renaming to hide the presence
of this intermediate level, if you wanted to.  I believe Robert
Eachus suggested this approach originally.

E.g.:
    package P.Hidden_Level is
    private
       ... -- private stuff
    end;

    package P.Hidden_Level.C1 is
      ...
    private
      ...  -- can see private decls of P.Hidden_Level
    end;

    with P.Hidden_Level.C1;
    package P.C1 renames P.Hidden_Level.C1;

Sorry for the confusion.

-Tuck

> Or did you mean for me to put I1 in the private part of P, not P.C1?
> 
> --STX
> package P is
> 
>    pragma Pure;
> 
> end P;
> 
> package P.C1 is
> private
> 
>   I1 : Integer;
> 
> end P.C1;
> 
> with P.C1;
> package P.C2 is
> 
>   I2 : Integer;
> 
> private
> 
>   I3 : Integer := P.C1.I1;
> 
> end P.C2;

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Private Children

[Richard D Riehle]

In article <376E9EEB.322A3F39@averstar.com>,
	Tucker Taft <stt@averstar.com> wrote:

>Oops, right you are.  The "idiom" I was misremembering was actually to
>create an extra level in the hierarchy, with all of the public
>children made into public children of this intermediate level,
>with the intermediate level spec having only a private part.
>You could then use library unit renaming to hide the presence
>of this intermediate level, if you wanted to.  I believe Robert
>Eachus suggested this approach originally.
>
>E.g.:
>    package P.Hidden_Level is
>    private
>       ... -- private stuff
>    end;
>
>    package P.Hidden_Level.C1 is
>      ...
>    private
>      ...  -- can see private decls of P.Hidden_Level
>    end;
>
>    with P.Hidden_Level.C1;
>    package P.C1 renames P.Hidden_Level.C1;
>
>-Tuck

 Thanks Tucker. This is a good idea. Also, consider,
 
       package P.Hidden_Level.Public_Level is
         type some-type is tagged private;
         -- some publicly exported services
       private
         ...
       end P.Hidden_Level.Public_Level ;

       package body P.Hidden_Level.Public_Level is
          -- implement exported services using the
          -- private services in the hierarchy since
          -- the body can see the private declarations
          -- of parent its units.
       end P.Hidden_Level.Public_Level;

 Might be a good technique for creating a cascade of child  packages
 where most of the hierarchy will consist of private specifications.
 The end of the hierarchy would be a public specification with a body   
 implemented using those private specifications.  This could prevent  
 premature use of a well-formed set of decompositions while still modeling  
 several levels of abstraction.   

 I wonder if this is also useful with Tucker's earlier example of 
 dispatching on privately declared operations. Seems there are some good        
 possibilities for powerful design strategies in this idea.  

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com

Re: Private Children

[Dale Stanbrough]

Richard D Riehle wrote:

"  Thanks Tucker. This is a good idea. Also, consider,
   
         package P.Hidden_Level.Public_Level is
           type some-type is tagged private;
           -- some publicly exported services
         private
           ...
         end P.Hidden_Level.Public_Level ;
  
         package body P.Hidden_Level.Public_Level is
            -- implement exported services using the
            -- private services in the hierarchy since
            -- the body can see the private declarations
            -- of parent its units.
         end P.Hidden_Level.Public_Level;"

It's still a bit ordinary though. The services offered in the
public level can't rely on abstractions advertised in the private
section, which I see as the major failure of this model.

Dale

Re: Private Children

[Richard D Riehle]

In article <dale-2206991424480001@192.168.0.2>,
	dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

>Richard D Riehle wrote:
>
>         package P.Hidden_Level.Public_Level is
>          -- code deleted

>         package body P.Hidden_Level.Public_Level is
            -- code deleted
>
>It's still a bit ordinary though. The services offered in the
>public level can't rely on abstractions advertised in the private
>section, which I see as the major failure of this model.

I see it differently -- not as a failure but as an opportunity
for powerful design of abstractions.  It might be the case that
we want to make some specifications available for type derivation
with a hierarchy of types, T'Class, as an implementation detail,
but hide those implementation details from the final user of 
some public class.  I wonder if this is one way for an Ada designer 
to differentiate implementation inheritance from interface inheritance. 

The type exported from the public package will be a pure interface,
a contract with some client.  The abstractions in the parent packages,
those with no public specifications, can safely focus on implementation
inheritance without the risk that the client will inadvertantly enter the
hierarchy at the wrong place.  

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

   
 

Re: Private Children

[Matthew Heaney]

On 22 Jun 1999 14:24, dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

>          package P.Hidden_Level.Public_Level is
>            type some-type is tagged private;
>            -- some publicly exported services
>          private
>            ...
>          end P.Hidden_Level.Public_Level ;
>   
>          package body P.Hidden_Level.Public_Level is
>             -- implement exported services using the
>             -- private services in the hierarchy since
>             -- the body can see the private declarations
>             -- of parent its units.
>          end P.Hidden_Level.Public_Level;"
> 
> It's still a bit ordinary though. The services offered in the public
> level can't rely on abstractions advertised in the private section,
> which I see as the major failure of this model.

Yes, but you can make use of them in the private region.  For example,
this would be a handy way to implement the full view (declared in the
private region) of a private type (whose partial view is declared in the
public region).

As was suggested in earlier posts:

1) Declare the private stuff in the private region of the root package.
   This way you can get rid of the intermediate package:

  package P is 
  private
    <private stuff here>
  end P;

  package P.C is
    <public stuff>
  private
    <private stuff that depends on private stuff in P>
  end P.C;


2) Declare the private stuff in a child, declare grandchildren that use
   that private stuff, and then rename the grandchildren as children:

  package P is
  end P;

  package P.Private_Stuff is
  private
    <private stuff>
  end;

  package P.Private_Stuff.C is
    <public stuff>
  private
    <private stuff that depends on private stuff in P.Private_Stuff>
  end;

  package P.C renames P.Private_Stuff.C;


The idea behind both of these schemes is to hide that fact that private
stuff is being used at all.  You don't what to expose publicly (in the
form of an intermediate package in the hierarchy) what is essentially an
implementation issue.

Re: Private Children

[Dale Stanbrough]

Matthew Heaney wrote:

" Yes, but you can make use of them in the private region.  For example,
  this would be a handy way to implement the full view (declared in the
  private region) of a private type (whose partial view is declared in the
  public region).
 
  As was suggested in earlier posts:
  
  1) Declare the private stuff in the private region of the root package.
     This way you can get rid of the intermediate package:
  
   [example deleted]"


I don't particuarly like this scheme, because it relies on all the children
having access to the private details of the type.
 
 
"2) Declare the private stuff in a child, declare grandchildren that use
    that private stuff, and then rename the grandchildren as children:
 
 [example deleted]
 
 
 The idea behind both of these schemes is to hide that fact that private
 stuff is being used at all.  You don't what to expose publicly (in the
 form of an intermediate package in the hierarchy) what is essentially an
 implementation issue."


Still not quite what i want to do. I would like to be able to build
subsystems where I have internal private packages whose type and
operations are visible within the private hierachy, but can also be
used to build (in the private parts of public packages) abstractions
that can be seen by everyone. (Having reread my original post i realise
now that i didn't mention private packages, which may have caused 
some confusion).

E.g.

   ----------------------------------------------------
   package P is
   end P;

   ----------------------------------------------------
   private package P.Private_Stuff is
      type PPS is private;
      blah blah blah;

   private
      <stuff>
   end;

   ----------------------------------------------------
   with P.Private_Stuff; use P.Private_Stuff;

   package P.Public_Stuff is
      type PPublic is private;
      blah blah blah;

   private
      type PPublic is -- a record with PPS components, 
                      -- or "new PPS;"
   end;
   ----------------------------------------------------

Of course there would have to be a restriction that the public section
of P.Public_Stuff could not export any of the information from the 
private package (e.g. no renames, subtypes etc).

Your 2nd proposal has the problem that implementation of types declared
in P.Private_Stuff can be seen by any child packages, so you loose any
ability to do hiding of abstractions -within- a hierachy.


Dale

Re: Private Children

[Matthew Heaney]

On 23 Jun 1999 11:54, dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

> Your 2nd proposal has the problem that implementation of types
> declared in P.Private_Stuff can be seen by any child packages, so you
> loose any ability to do hiding of abstractions -within- a hierachy.

But that's already the case:

  package P is

    type T is tagged private;
    ...

  private

    type T is ...;

  end P;


  package P.C1 is ...

  package P.C2 is ...


Every child (C1, C2) has access to the private part of its parent (P).
There's no such thing as "hiding within a hierarchy."

Child packages were designed not to hide visibility from within the
hierarchy.  They were designed to /deliberately/ expose the private part
to children, and to allow you to easily identify which packages have
that private knowledge.

Re: Private Children

[Dale Stanbrough]

Matthew Heaney wrote:

" Every child (C1, C2) has access to the private part of its parent (P).
  There's no such thing as "hiding within a hierarchy.""

There is. Consider the following...


   pacakge P is
   end P;

   package P.A is
      type X is private;
   ...
   end A;


   with P.A;
   package P.B is
      type Y is private;
      -- operations on Y

   private
      type Y is record
            Item : X;
         end record;
   end P.B;


Clearly package P.B has no access to the private implementations
of package P.A (and they -are- in the same hierachy, it's just that
one is not a lineal (package) descendent of the other).

Consider the following...

The example above compiles fine. External users of type Y are happy.
Package P.B is prevented from knowing the internal implementation of
type X.

But let's also assume that we didn't want to give access to type X to
the rest of the world. What I would -like- to do is to make P.A private,
so that it can't be seen, but still retain type X's private status.

It would be nice if i could simply make P.A. a private package.
Unfortunately Ada confuses "compilation privacy" with "implementation
privacy". I am forced (simply because I want to hide some internal 
details) to sacrifice my privacy designs to the gods of compilation
efficiency (which is the opposite of what "private" means in the
rest of Ada).


" Child packages were designed not to hide visibility from within the
  hierarchy.  They were designed to /deliberately/ expose the private part
  to children, and to allow you to easily identify which packages have
  that private knowledge."


Yes I know that, but I'm not concerned about parent/child packages, but
about sibling (or rather non lineal descendant) packages/privacy issues.

I think that the current situation forces too much exposure of
implementation issues that will cause package hierachies to end up 
a large entagled mess, because we are continually forced to abandon
internal privacy goals to meet external ones.

Dale

Re: Private Children

[Richard D Riehle]

In article <dale-2306991359560001@dale.cs.rmit.edu.au>,
	dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

>Yes I know that, but I'm not concerned about parent/child packages, but
>about sibling (or rather non lineal descendant) packages/privacy issues.
>
>I think that the current situation forces too much exposure of
>implementation issues that will cause package hierachies to end up 
>a large entagled mess, because we are continually forced to abandon
>internal privacy goals to meet external ones.

The Ada private part is analogous to the C++ protected part.  A
derivation of a C++ class may see the protected part of its parent.
Ada has ways to strengthen the encapsulation if you wish.  Private
packages are one way.  Another useful technique is opaque types.

An opaque type is a type that contains nothing but a reference to
data. This is quite easy using Ada's incomplete type definition.
These can be tagged for extensibility while hiding all the details
within a package body.  Consider,

     package P is
       type T is tagged private;
       -- operations on T
     private 
       type Item;
       type Item_Pointer is access all Item;
       type T is tagged record
          Data : Item_Pointer;  -- a reference to hidden data
       end record;
     end P;

Now T can still be extended, but the implementation of Item
is deferred to the package body.  If you want to be really clever,
you can create a private child package of P where Item is fully
defined in the private specification and with'ed into the body of
P.  This enforces the rule that nothing but a package body rooted
at P can access the public specification of the private child.  
This preserves extensibility within the hierarchy but prevents 
access by any ordinary client.  

This example follows the Modula-2 convention for information 
hiding using opaque types. Note that Modula-3 improves upon this
through reference types that are followed with a reserved word, 
REVEAL,in the IMPLEMENTATION MODULE.  

In the final analysis, though, encapsulation is something like the
lock on a safe that is intended to keep honest people honest. If 
someone is determined to break encapsulation, they will find a way
to do it, even if they have to crack open your package body and
perform "open heart surgery."

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: Private Children

[John Duncan]

>This example follows the Modula-2 convention for information
>hiding using opaque types. Note that Modula-3 improves upon this
>through reference types that are followed with a reserved word,
>REVEAL,in the IMPLEMENTATION MODULE.


Just a note: M3 allows the revelation of opaque subtypes at the interface
level as well. That way you can publish a number of increasingly-challenging
interfaces to a type, some of them unsafe, provided that the base
implementation exports all of the interfaces. This way, you can have
something like

INTERFACE Thingy;
    TYPE T <: Public;
    TYPE Public = OBJECT METHODS safeMethods END;

    ...
END Thingy;

UNSAFE INTERFACE ThingyUnsafe;
    IMPORT Thingy;
    REVEAL Thingy.T <: Unsafe;
    TYPE Unsafe =
        Thingy.T
        OBJECT attributes
        METHODS
            unsafeMethods
        END;

    ...
END ThingyUnsafe;

UNSAFE MODULE Thingy EXPORTS ThingyUnsafe;
IMPORT ThingyUnsafe;
    REVEAL T =
    ThingyUnsafe.Unsafe
    OBJECT
        moreAttributes
    METHODS
        moreMethods
    OVERRIDES
        ifaceMethod := MyMethodProcedure;
    END;

    ...

END Thingy;

The little "<:" operator tells the compiler about the subtyping relation.
Each of the times T is declared as a subtype, it becomes more concrete, but
not concrete enough to compile. When it comes down to the module level,
someone has to define the type concretely. In order to do this, the methods
are usually null until someone comes along and overrides the previous
methods. It all works out very, very nicely.

A lot of people on the m3 ng wonder whether the Ada committee reviewed
opaque subtypes at all. It is a very neat feature for deep-down systems
programming. There is no particular reason why unsafe things have to be
published outside a library, but they are usually very useful within the
library. That's where the opaque subtyping and partial revelations come in.

(for more info on modula-3, go to http://www.m3.org/ )

-John

Re: Private Children

[Vladimir Olensky]

Richard D Riehle wrote in message <7kr4pc$bb9@dfw-ixnews15.ix.netcom.com>...
>In article <dale-2306991359560001@dale.cs.rmit.edu.au>,
> dale@cs.rmit.edu.au (Dale Stanbrough) wrote:
>
>This example follows the Modula-2 convention for information
>hiding using opaque types. Note that Modula-3 improves upon this
>through reference types that are followed with a reserved word,
>REVEAL,in the IMPLEMENTATION MODULE.


There is very interesting article about using M3 opaque types. It was
published in Dr.Dobb's journal
in October 1995 and now it is available online at
http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html

It includes   C++, Ada 95 and M3 examples.
I think everyone find this article  very interesting.

Ada private child packages come very close to M3 opaque types.

Regards,
Vladimir Olensky

Re: Private Children

[Richard D Riehle]

In response to my example of opaque types in Ada,

In article <7kra6p$t5h$1@remarQ.com>,
	"Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:

>There is very interesting article about using M3 opaque types. It was
>published in Dr.Dobb's journal
>in October 1995 and now it is available online at
>http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html

The article you cited by Steve Freeman is certainly a thoughtful and
fair treatment of some of the issues related to interface inheritance
versus implementation inheritance.  It is especially potent in highlighting
some of the drawbacks of C++, but I doubt any C++ users from the Dr. Dobbs
readership paid serious attention to that.

In Mr. Freeman's Ada example, he assumes that the private part of
the package must contain a complete view of the data. That is exactly 
the opposite of the example I posted earlier. In Ada, we can declare
an incomplete type, an access to that type, enclose within a tagged 
record a value of the access type, and defer the full description of the
data until later. This is the essence of an opaque type. Opaque types 
are convenient in both Ada and Modula-3 because of their clear separation 
of interface module (package specification) from implementation module
(package body).  This is more difficult in Java, C++, and even Eiffel, as 
demonstrated in Mr. Freeman's article.

Although the Ada opaque type must be implemented using an access type,
it does overcome one of the complaints Mr. Freeman has about Ada's
structure:  changes can be made to the full data definition, the 
implementation, in the package body without changing the interface. 
I agree that the use of an Ada access type to design an opaque type is 
not quite as elegant as the semantics of the Modula-3 REVEAL keyword. 
However, it is effective, clean, efficient and expressive enough
to permit a an opaque type design that distinguishes implementation 
inheritance from specification inheritance.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

 

Re: Private Children

[Hyman Rosen]

Richard D Riehle <laoXhai@ix.netcom.com> writes:
> In Mr. Freeman's Ada example, he assumes that the private part of
> the package must contain a complete view of the data. That is exactly 
> the opposite of the example I posted earlier.

which was --

     package P is
       type T is tagged private;
       -- operations on T
     private 
       type Item;
       type Item_Pointer is access all Item;
       type T is tagged record
          Data : Item_Pointer;  -- a reference to hidden data
       end record;
     end P;

> In Ada, we can declare an incomplete type, an access to that type,
> enclose within a tagged record a value of the access type, and defer
> the full description of the data until later. This is the essence of
> an opaque type. Opaque types are convenient in both Ada and Modula-3
> because of their clear separation of interface module (package
> specification) from implementation module (package body).  This is
> more difficult in Java, C++, and even Eiffel, as demonstrated in
> Mr. Freeman's article.

In C++ we can do the following. I'm not sure if I've duplicated the
semantics you're aiming for, but I think I did. Unless I'm not
understanding your intent, I don't see why my C++ is any more
difficult than your Ada.

class P
{
private:
	class Item;
	typedef Item *Item_Pointer;
public:
	class T
	{
	public:
		// operations on T
	private:
		Item_Pointer Data;
	};
};

Re: Private Children

[Richard D Riehle]

In article <t7emj1y32b.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>In C++ we can do the following. I'm not sure if I've duplicated the
>semantics you're aiming for, but I think I did. Unless I'm not
>understanding your intent, I don't see why my C++ is any more
>difficult than your Ada.
>
>class P
>{
>private:
>	class Item;
>	typedef Item *Item_Pointer;
>public:
>	class T
>	{
>	public:
>		// operations on T
>	private:
>		Item_Pointer Data;
>	};
>};

I would first refer you to Mr. Freeman's article since he has more
eloquently examined this issue than I.   A key difference between
C++ and Ada is that Ada _requires_ a separation of specification 
from implementation.  This is also true, for the most part, of the
Modula series.  Although the semantics of an opaque type can be
expressed in C++, I believe the best and most direct expression 
of this mechanism is found in Modula-3, then Ada, and lastly other
languages, such as C++.  

The argument about whether a particular construct _can_ be expressed
in this or that language is often far from the issue of direct
expressibility.  There are certain things that are more expressible in
C++ than Fortran, others more expressible in Fortran than C++, and still
others better expressed in COBOL than in C++ or Java. There are ideas 
we can express in a single word in Japanese or Chinese that might take a
paragraph in English.  This does not make Japanese better than English. 
It is simply a matter of ease of expressibility.  Also, the issue of
expressive power is quite subjective and almost always derives from one's
personal preferences and experiences, seldom from faultless logic.

I am sure there are Ada enthusiasts who will disagree with my contention
that Modula-3 is better at expressing opaque types than Ada.  Overall,
my language preference still remains Ada, even though C++, Java, 
Modula-3 and Object COBOL all have features of expressiveness for certain
constructs that are better than a similar construct in Ada.  

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: Private Children

[Dale Stanbrough]

Richard D Riehle wrote:

  An opaque type is a type that contains nothing but a reference to
  data. This is quite easy using Ada's incomplete type definition.
  These can be tagged for extensibility while hiding all the details
  within a package body.  Consider..."

Yes, but that forces me to change the representation that I may have
chosen for very good reasons, just to get around what I view is a 
problem in how "private" works for packages.


" In the final analysis, though, encapsulation is something like the
  lock on a safe that is intended to keep honest people honest. If 
  someone is determined to break encapsulation, they will find a way
  to do it, even if they have to crack open your package body and
  perform "open heart surgery.""


Yes, but this doesn't really address the issue at hand. What I am
arguing is that Ada could have been -more- helpful than it is in
supporting encapsulation, not that we need not worry about it encapsulation
because people can break it if they want to (after
all anyone can use unchecked-perversion to open up any private type
they like!).

Certainly encapsulation doesn't (or rather in Ada's case, shouldn't)
end at the level of package hierachies.


Dale

Re: Private Children

[Robert Dewar]

In article <7klja3$c0p$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> In article <m3bteacxb8.fsf@mheaney.ni.net>,
>   Matthew Heaney <matthew_heaney@acm.org> wrote:
> > Can a public child package with its private sibling?
> >
>
> Almost exactly one month ago, I posted the exact same
> question. Go to deja.com and search for a thread titled
> "Children of private nhcompilation units" to see the
> discussion.

If you go there you will find out that it is a totally
unrelated issue, not at all "the exact same question".


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Private Children

[Dale Stanbrough]

Matthew Heaney wrote:

" Can a public child package with its private sibling?
  
  According to my compiler, the answer is no.  When I try to compile the
  unit below (P.C2), I get the following error message:
  
  gcc -c -gnatc /home/matt/p-c2.ads
  p-c2.ads:1:06: current unit must also be private descendant of "P"
  
  
  Public child P.C2 only uses the entity provided by its private sibling
  P.C1 in its private region.  What is the rationale for making this
  illegal?"


Tucker Taft once explained that this allows for "compilation privacy"
(my description). This guarentees that if a private package spec changes,
you don't have to do any recompilation of any public packages (just
relinking).

Personally I don't care for it, and would have much preferred
"implementation privacy" where changes to a spec of a private
package could still mean that public clients may have to be
recompiled, but not updated in any other way.

Dale