Extended revelation

Extended revelation

[Jean-Marc Bourguet]

Hi all,

I've a package which export to his users some usefull types and
routines. In his private part, I've some more declarations
which are exported to his child packages.

My problem is that in one of the child package, I'd like to make
public one of the private type (T). I had though that

	type T1 is private;
    private
	subtype T1 is T;

but that's not valid. As renanimg does not apply to types I can't see
an easy way to do it. Currently I'm using

	type T1 is private;
    private
	type T1 is new T;

I've also considered exporting T from the parent package, but neither
solution please me.

-- Jean-Marc


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Extended revelation

[Matthew Heaney]

In article <873q03$alb$1@nnrp1.deja.com> , Jean-Marc Bourguet 
<bourguet@my-deja.com>  wrote:

> My problem is that in one of the child package, I'd like to make
> public one of the private type (T). I had though that
>
>  type T1 is private;
>     private
>  subtype T1 is T;
>
> but that's not valid.

No, you can't implement the full view of a private type as a subtype.


> As renanimg does not apply to types I can't see
> an easy way to do it. Currently I'm using
>
>  type T1 is private;
>     private
>  type T1 is new T;

Yes, this is one way to do it.  One issue with this solution is that
there's no clean separation between public and private namespaces.  That
is, certain (usually predefined) operations can become directly visible
at the point of declaration of the full view (here, T), and they may
conflict with operations declared for the partial view.

The best thing to do is always implement the full view of a private type
as a record:

package P is

  type T1 is private;

private

  type T1 is
    record
      O : T;
    end record;

end P;

Now there is no problem.

Indeed, I consider it a design flaw in the language, in that it allows
you to implement the full view as something other than a record.  I wish
they had designed Ada83 private types the same way they designed Ada95
tagged types.


> I've also considered exporting T from the parent package, but neither
> solution please me.

I'm not sure what you mean by this.

Matt

Re: Extended revelation

[Mark Lundquist]

Jean-Marc Bourguet wrote:

> Hi all,
>
> I've a package which export to his users some usefull types and
> routines. In his private part, I've some more declarations
> which are exported to his child packages.
>
> My problem is that in one of the child package, I'd like to make
> public one of the private type (T).

That is, you want to export the type.  Its definition would remain
private, of course...

> I had though that
>
>         type T1 is private;
>     private
>         subtype T1 is T;
>
> but that's not valid.

Right.  A subtype declaration doesn't complete a private type
declaration.

> As renanimg does not apply to types I can't see
> an easy way to do it. Currently I'm using
>
>         type T1 is private;
>     private
>         type T1 is new T;

>
>
> I've also considered exporting T from the parent package, but neither
> solution please me.

You're right, privately deriving T1 from T does seem crummy (for one
thing, none of T's primitive operations will be publicly visible for
T1...)

It kind of seems like simply making T visible (still private) in the
parent package is what you want to do.  What do you find objectionable
about that?

If it "feels" right for T to be exported from the child package rather
than the parent, why not move the definition of T to the child
package?!?   Since T is already  private in the parent, I know you do
not have any other declarations in the visible part of the parent that
depend on the (full) definition of T.  Did you know that the body of the
parent can say "with Parent.Child;"?  If you have declarations in the
private part of the parent that require the full definition of T, then
perhaps you could solve it by moving those declarations to a private
child...?

Re: Extended revelation

[Jean-Marc Bourguet]

> From: "Matthew Heaney" <matthew_heaney@acm.org>
> Subject: Re: Extended revelation
> Date: Mon, 31 Jan 2000 12:54:23 GMT
> Organization: EarthLink Network, Inc.

> > I've also considered exporting T from the parent package, but
> > neither
> > solution please me.
>
> I'm not sure what you mean by this.

I think indeed you have not understood what I want to do. What I really
want is something like modula-3 partial revelation: one package
providing multiples interface. In Ada95, a package has two interfaces,
one for the general public, one for his children. What I want is
multiple public interfaces. Until now, using child package has
permetted me to do this cleanly and here is the first example I come
with where I do not find a clean solution in Ada.

-- Jean-Marc


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Extended revelation

[Matthew Heaney]

In article <87446a$h6u$1@nnrp1.deja.com> , Jean-Marc Bourguet 
<bourguet@my-deja.com>  wrote:

> I think indeed you have not understood what I want to do. What I really
> want is something like modula-3 partial revelation: one package
> providing multiples interface. In Ada95, a package has two interfaces,
> one for the general public, one for his children. What I want is
> multiple public interfaces. Until now, using child package has
> permetted me to do this cleanly and here is the first example I come
> with where I do not find a clean solution in Ada.

Indeed I still don't know what you want to do.  (Perhaps this is because
I am unfamiliar with Modula-3.)

Will static polymorphism work?

package P1 is

  type T is private;

  procedure Op (O : in out T);
...
end P1;

package P2 is

  type T is private;

  type Op (O : in out T);
...
end P2;


If you want "multiple public interfaces," then why not implement
"multiple public interfaces"?  That is, different abstractions with
identical public parts.

If you want to statically bind to the "virtual abstraction" reified by
P1 and P2, then use library-level package renaming:

with P1;
package P renames P1;

or

with P2;
package P renames P2;

Clients of "abstract" package P don't know or care which "concrete"
package is used to implement P.

That's how to handle it on the supplier side.  Another way is to use
"implementation inheritance," and import the type as generic formal
parameters:

generic
  type T is private;
  with procedure Op (O : in out T) is <>;
package Generic_Client is ...;

To make a client, you just supply any type with a matching profile:

with P1; use P1;
package Client is new Generic_Client (T);

or

with P2; use P2;
package Client is new Generic_Client (T);


But I'm only guessing what it is you're trying to do.  Perhaps if you
provide a small amount of code, then we can give you more specific help
to solve your problem.

Re: Extended revelation

[Vladimir Olensky]

Matthew Heaney wrote in message ...
>In article <87446a$h6u$1@nnrp1.deja.com> , Jean-Marc Bourguet
><bourguet@my-deja.com>  wrote:
>
>> I think indeed you have not understood what I want to do. What I really
>> want is something like modula-3 partial revelation: one package
>> providing multiples interface. In Ada95, a package has two interfaces,
>> one for the general public, one for his children. What I want is
>> multiple public interfaces. Until now, using child package has
>> permetted me to do this cleanly and here is the first example I come
>> with where I do not find a clean solution in Ada.
>
>Indeed I still don't know what you want to do.  (Perhaps this is because
>I am unfamiliar with Modula-3.)


You may want to read the article "Partial Revelation and Modula-3" at:
http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html
I think after reading it the intent of Jean-Marc Bourguet  will be clear to
you.

M3 language definition could be found at:
http://www.research.digital.com/SRC/m3defn/html/m3.html

M3 home pages at

www.m3.org and
http://www.research.digital.com/SRC/modula-3/html/home.html

Regards,
Vladimir Olensky

Re: Extended revelation

[Richard D Riehle]

In article <87446a$h6u$1@nnrp1.deja.com>,
	Jean-Marc Bourguet <bourguet@my-deja.com> wrote:


>I think indeed you have not understood what I want to do. What I really
>want is something like modula-3 partial revelation: one package
>providing multiples interface. In Ada95, a package has two interfaces,
>one for the general public, one for his children. What I want is
>multiple public interfaces. Until now, using child package has
>permetted me to do this cleanly and here is the first example I come
>with where I do not find a clean solution in Ada.

You are correct about the excellent approach of Modula-3 in support
of what some would call opaque types, a foundation mechanism
for revelation. This can be done in Ada, but in a more awkward manner 
than in Modula-3.  

  package P1 is
    type T1 is tagged private;
    -- other public declarations
  private
    type Data;
    type T1 is access Data;
  end P1;

  package body P1 is
    type Data is record ... end record;
    -- more declarations
  end P1;

This is quite similar to the style used in Modula-2, if you remember
that far back.  It is similar to, but not as expressive as, the
revelation mechanism in Modula-3.

Sometimes we might want to make the private type extensible.  

  package P2 is
    type T2 is tagged private;  -- usually an abstract type
    -- other declarations
  private
    type Data;
    type Pointer is access Data;
    type T2 is tagged record
       X : Pointer;
    end record;
  end P2;

This provides extensible inheritance while encapsulating all information
about the Data in the implementing code. The package body will be coded
to reflect the actual data.  One benefit of this is the ability to 
acquire the data descriptions, at the implementation level, from some
entirely different package, even a private child unit in the same
hierarchy.  In this respect, Ada has some benefits over Modula-3 in
spite of its awkwardness vis a vis designing an opaque type.  

This goes back, again, to the issue of expressibility versus 
expressiveness. Modula-3 is much more expressive of opaque types 
than Ada.  Ada is slightly more expressive of modular composition and
independence than Modula-3.  There is no perfect programming language. 

There is an upside, in expressiveness, to revelation.  There is a 
downside in the branded reference mechanism required to support
opaque types and revelation.  Often, in Modula-3, an error is not 
discovered until link time.  In Ada, every type mismatch will
be caught at compile time.  This may be one of those things that
is seldom a problem, but it does become significant in a large
scale software system consisting of lots of modules.  

Richard Riehle
richard@adaworks.com