comp.lang.ada
 help / color / mirror / Atom feed
* Type extension questions
@ 1995-03-22  0:25 Harry Koehnemann
  1995-03-22 12:01 ` Robb Nebbe
  1995-03-23 22:03 ` Tucker Taft
  0 siblings, 2 replies; 12+ messages in thread
From: Harry Koehnemann @ 1995-03-22  0:25 UTC (permalink / raw)


I have a couple questions on Ada95 tagged types.  These appear to be
easy questions, but I can't seem to locate an answer for either.
LRM references would also be appreciated with an answer.

1) Is it possible to derive a type such that the parent operations are not
   available to the user of the new type?  This question is equivalent to
   the ability to do private inheritance ala C++ - class B: private A { ...};
   I would assume the answer is yes, but haven't yet figured out how.

2) Can a derived type declare a component with the same name as a parent
   component?  At the risk of being lectured on GNAT's incompleteness :),
   GNAT allows a new same-name components if the parent type is private and
   the child type is public, but does gives an error if the child and parent
   are both public or private.  I assume the answer is one or the other,
   not "if one is private and one is public...".  Other OO languages allow
   this in their inheritance and I assume Ada95 does as well.

Thanks.

--
Harry Koehnemann			Arizona State University
hek@asu.edu				Computer Science Department



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-22  0:25 Type extension questions Harry Koehnemann
@ 1995-03-22 12:01 ` Robb Nebbe
  1995-03-23 22:05   ` Harry Koehnemann
  1995-03-23 22:03 ` Tucker Taft
  1 sibling, 1 reply; 12+ messages in thread
From: Robb Nebbe @ 1995-03-22 12:01 UTC (permalink / raw)


In article <D5tFuE.1vx@ennews.eas.asu.edu>, koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) writes:
|> I have a couple questions on Ada95 tagged types.  These appear to be
|> easy questions, but I can't seem to locate an answer for either.
|> LRM references would also be appreciated with an answer.
|> 
|> 1) Is it possible to derive a type such that the parent operations are not
|>    available to the user of the new type?  This question is equivalent to
|>    the ability to do private inheritance ala C++ - class B: private A { ...};
|>    I would assume the answer is yes, but haven't yet figured out how.

Yes. For example when you need a type to be controlled typically you don't
want to expose the finalize, initialize and adjust operations to the client
so you write:

	package P is

	    type T is private;

	private

	    type T is new Ada.Finalization.Controlled with ...

	    procedure Adjust( Object : in out T );

	    ...

	end P;

A private_type_declaration must be completed with a
full_type_declaration which is in 3.2.1

Robb Nebbe



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-22  0:25 Type extension questions Harry Koehnemann
  1995-03-22 12:01 ` Robb Nebbe
@ 1995-03-23 22:03 ` Tucker Taft
  1 sibling, 0 replies; 12+ messages in thread
From: Tucker Taft @ 1995-03-23 22:03 UTC (permalink / raw)


Harry Koehnemann (koehnema@enuxsa.eas.asu.edu) wrote:

: I have a couple questions on Ada95 tagged types.  These appear to be
: easy questions, but I can't seem to locate an answer for either.
: LRM references would also be appreciated with an answer.

: 1) Is it possible to derive a type such that the parent operations are not
:    available to the user of the new type?  This question is equivalent to
:    the ability to do private inheritance ala C++ - class B: private A { ...};
:    I would assume the answer is yes, but haven't yet figured out how.

Just declare the new type as a tagged private type (RM95 7.3(2)):

   type T is tagged private;
   ...
 private
   type T is new P with record ...

Or, if you want to make it visible that you are derived from some
ancestor of P, but not that you are derived from P directly
(see RM95 7.3(3)):

   type T is new P_Ancestor with private;
   ...
 private
   type T is new P with record ...  
         -- presuming P is descended from P_Ancestor

Even simpler is to use the "privately" inherited type as a component.
In many cases, type extension is overkill for purely private "implementation" 
inheritance.  Simply making P a component eliminates any complexity
relating to multiple inheritance, etc.

: 2) Can a derived type declare a component with the same name as a parent
:    component?  At the risk of being lectured on GNAT's incompleteness :),
:    GNAT allows a new same-name components if the parent type is private and
:    the child type is public, but does gives an error if the child and parent
:    are both public or private.  I assume the answer is one or the other,
:    not "if one is private and one is public...".  Other OO languages allow
:    this in their inheritance and I assume Ada95 does as well.

Only inherited subprograms can be overridden; inherited 
components cannot (RM95 8.3(9-13)).

You may not repeat names if both components would ever be visible
at the same place (RM95 8.3(26)).  

This rule is repeated as a Note in RM95 3.9.1(9) -- Note #69 of Section 3.

What this means is that you can reuse a name of a non-discriminant
component only if the parent type is private.  You can reuse
the name of a (visible) discriminant of the parent only if a new 
discriminant_part is given in the declaration of the type extension.

Even if the parent type is private, you can't reuse the name
if the record extension is declared in a child of the package
containing the private type declaration, because once you 
get to the private part or body of the child, both would
be visible (RM95 7.3.1(4)).  (I fear that as I now reread 7.3.1(4) 
and 8.3(26), the intent of these rules for handling this special case 
might have gotten a bit garbled in the RM-ease...)

: Thanks.

: --
: Harry Koehnemann			Arizona State University
: hek@asu.edu				Computer Science Department

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-22 12:01 ` Robb Nebbe
@ 1995-03-23 22:05   ` Harry Koehnemann
  1995-03-25  6:59     ` Cyrille Comar
  1995-03-25  7:13     ` Cyrille Comar
  0 siblings, 2 replies; 12+ messages in thread
From: Harry Koehnemann @ 1995-03-23 22:05 UTC (permalink / raw)


In article <1995Mar22.125057@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
>In article <D5tFuE.1vx@ennews.eas.asu.edu>, koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) writes:
>|> 
>|> 1) Is it possible to derive a type such that the parent operations are not
>|>    available to the user of the new type?  This question is equivalent to
>|>    the ability to do private inheritance ala C++ - class B: private A { ...};
>|>    I would assume the answer is yes, but haven't yet figured out how.
>
>Yes. For example when you need a type to be controlled typically you don't
>want to expose the finalize, initialize and adjust operations to the client
>so you write:
>
>	package P is
>
>	    type T is private;
>
>	private
>
>	    type T is new Ada.Finalization.Controlled with ...
>
>	    procedure Adjust( Object : in out T );

I don't think my request was clear enough.  This is close, but I'd
like P.T to be extensible.  The above approach hides the fact that P.T
is tagged and therefore extensions of P.T are not allowed.  What I
really want is private inheritance ala C++.

Thanks for the reply.  Any other suggestions?

--
Harry Koehnemann			Arizona State University
hek@asu.edu				Computer Science Department



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-23 22:05   ` Harry Koehnemann
@ 1995-03-25  6:59     ` Cyrille Comar
  1995-03-25  7:13     ` Cyrille Comar
  1 sibling, 0 replies; 12+ messages in thread
From: Cyrille Comar @ 1995-03-25  6:59 UTC (permalink / raw)


koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) writes:
: In article <1995Mar22.125057@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
: >In article <D5tFuE.1vx@ennews.eas.asu.edu>, koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) writes:
: >|> 
: >|> 1) Is it possible to derive a type such that the parent operations are not
: >|>    available to the user of the new type?  This question is equivalent to
: >|>    the ability to do private inheritance ala C++ - class B: private A { ...};
: >|>    I would assume the answer is yes, but haven't yet figured out how.
: >
: >Yes. For example when you need a type to be controlled typically you don't
: >want to expose the finalize, initialize and adjust operations to the client
: >so you write:
: >
: >	package P is
: >
: >	    type T is private;
: >
: >	private
: >
: >	    type T is new Ada.Finalization.Controlled with ...
: >
: >	    procedure Adjust( Object : in out T );
: 
: I don't think my request was clear enough.  This is close, but I'd
: like P.T to be extensible.  The above approach hides the fact that P.T
: is tagged and therefore extensions of P.T are not allowed.  What I
: really want is private inheritance ala C++.
: 
: Thanks for the reply.  Any other suggestions?
: 
: --
: Harry Koehnemann			Arizona State University
: hek@asu.edu				Computer Science Department
-- 
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-23 22:05   ` Harry Koehnemann
  1995-03-25  6:59     ` Cyrille Comar
@ 1995-03-25  7:13     ` Cyrille Comar
  1995-03-27  0:00       ` Norman H. Cohen
  1995-03-27 17:29       ` Harry Koehnemann
  1 sibling, 2 replies; 12+ messages in thread
From: Cyrille Comar @ 1995-03-25  7:13 UTC (permalink / raw)


koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) writes:
: I don't think my request was clear enough.  This is close, but I'd
: like P.T to be extensible.  The above approach hides the fact that P.T
: is tagged and therefore extensions of P.T are not allowed.  What I
: really want is private inheritance ala C++.
: 
: Thanks for the reply.  Any other suggestions?

(sorry for previous empty message, I try again)

Don't try to be too close to C++, this doesn't fit Ada's
model. "Private inheritance" is meaningless in Ada since "Private" is
a caracteristic of packages and inheritance a characteristic of types
but you can still do something very close from what you want :
package P is
   type T is tagged private;
   procedure Visible_Method (X : T);
private 
   procedure Private_Method (X : T);
   type T is ...
end P;

with P; use P;
package Q is 
  type T2 is new T with ....;
end Q;

a client of Q can use the inherited Visible_Method but not
Private_Method (unless the client happen to be child of P but this is
an other story... ;-)
-- 
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-25  7:13     ` Cyrille Comar
@ 1995-03-27  0:00       ` Norman H. Cohen
  1995-03-30  0:00         ` Cyrille Comar
  1995-03-27 17:29       ` Harry Koehnemann
  1 sibling, 1 reply; 12+ messages in thread
From: Norman H. Cohen @ 1995-03-27  0:00 UTC (permalink / raw)


In article <3l0frd$b9t@lang8.cs.nyu.edu>, comar@cs.nyu.edu (Cyrille Comar)
writes: 
|> koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) writes: 
...
|> :                                                             What I
|> : really want is private inheritance ala C++.
|>
|> Don't try to be too close to C++, this doesn't fit Ada's
|> model. "Private inheritance" is meaningless in Ada since "Private" is
|> a caracteristic of packages and inheritance a characteristic of types

No, there is a direct Ada analog to a C++ class with a private base
class, namely a private type implemented as a tagged derived type: 

   package Base_Type_Package is
      type Base_Type is tagged ...;
      ...
   end Base_Type_Package;

   with Base_Type_Package;
   package Derived_Type_Package is
      type Derived_Type is private;
      procedure Some_Operation (X: in out Derived_Type);
      ...
   private
      type Derived_Type is new Base_Type_Package.Base_Type with ...;
   end Derived_Type_Package;

--
Norman H. Cohen    ncohen@watson.ibm.com




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-25  7:13     ` Cyrille Comar
  1995-03-27  0:00       ` Norman H. Cohen
@ 1995-03-27 17:29       ` Harry Koehnemann
  1995-03-27 20:26         ` Robert I. Eachus
  1995-03-27 20:37         ` Kennel
  1 sibling, 2 replies; 12+ messages in thread
From: Harry Koehnemann @ 1995-03-27 17:29 UTC (permalink / raw)


In article <3l0frd$b9t@lang8.cs.nyu.edu> comar@cs.nyu.edu (Cyrille Comar) writes:
>Don't try to be too close to C++, this doesn't fit Ada's
>model. "Private inheritance" is meaningless in Ada since "Private" is
>a caracteristic of packages and inheritance a characteristic of types
>but you can still do something very close from what you want :

Well, yes and no.  What I really want to do is restrict the interface
to a type.  It might help to see an example.  Let's pretend we have 2
abstract data types, where one is an extension of the other:

    class List {
	public:  Set (...) { ...}
	private: ...;
    };

    class Stack : private List {
	public:  Push() { ...}
	private: ...;
    };

It is not appropriate for a Stack to invoke Set.  One could argue that
Stack has-a List instead of Stack is-a list (I think Tucker Taft made
this argument earlier).  Bottom line - I guess there is no way to
perform private inheritance, as shown in the above example, in Ada95,
which was my question.  Thanks for the input.

BTW - I am by no means saying Ada95 should have included such a
feature (in fact, I am not a believer in restricting interfaces and
think that it clutters a design).  I'm just getting my Ada95 facts
straight.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-27 17:29       ` Harry Koehnemann
@ 1995-03-27 20:26         ` Robert I. Eachus
  1995-03-29  0:00           ` Harry Koehnemann
  1995-03-27 20:37         ` Kennel
  1 sibling, 1 reply; 12+ messages in thread
From: Robert I. Eachus @ 1995-03-27 20:26 UTC (permalink / raw)


In article <D640KK.63D@ennews.eas.asu.edu> koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) writes:


 >      class List {
 >	   public:  Set (...) { ...}
 >	   private: ...;
 >      };

    type List is new Set with private;

  >     class Stack : private List {
  >	   public:  Push() { ...}
  >	   private: ...;
  >     };

    type Stack is tagged private;

    procedure Push(...

  private

    type Stack is new List with...

 > BTW - I am by no means saying Ada95 should have included such a
 > feature (in fact, I am not a believer in restricting interfaces and
 > think that it clutters a design).  I'm just getting my Ada95 facts
 > straight.

   But it does include such a feature, the syntax is somewhat
different.

--

					Robert I. Eachus

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-27 17:29       ` Harry Koehnemann
  1995-03-27 20:26         ` Robert I. Eachus
@ 1995-03-27 20:37         ` Kennel
  1 sibling, 0 replies; 12+ messages in thread
From: Kennel @ 1995-03-27 20:37 UTC (permalink / raw)


Harry Koehnemann (koehnema@enuxsa.eas.asu.edu) wrote:
> Well, yes and no.  What I really want to do is restrict the interface
> to a type.  It might help to see an example.  Let's pretend we have 2
> abstract data types, where one is an extension of the other:

>     class List {
> 	public:  Set (...) { ...}
> 	private: ...;
>     };

>     class Stack : private List {
> 	public:  Push() { ...}
> 	private: ...;
>     };

> It is not appropriate for a Stack to invoke Set.  One could argue that
> Stack has-a List instead of Stack is-a list (I think Tucker Taft made
> this argument earlier).  Bottom line - I guess there is no way to
> perform private inheritance, as shown in the above example, in Ada95,
> which was my question.  Thanks for the input.

I wouldn't call this 'has-a' *or* 'is-a'.

I would call it 'is-implemented-as-a'.

For example, we may want many features from List to be *public*, and
yet still *not* allow a Stack to be substituted at run-time for a List.
{i.e. divorce subtyping from inheritance, a convenient idea i've found}

How ought one do this in Ada?

cheers
matt




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-27 20:26         ` Robert I. Eachus
@ 1995-03-29  0:00           ` Harry Koehnemann
  0 siblings, 0 replies; 12+ messages in thread
From: Harry Koehnemann @ 1995-03-29  0:00 UTC (permalink / raw)


eachus@spectre.mitre.org (Robert I. Eachus) writes:
>
>    type Stack is tagged private;
>
>  private
>
>    type Stack is new List with...

Yup, that's what I was looking for.  Thanks.

Harry.
--
Harry Koehnemann			Arizona State University
hek@asu.edu				Computer Science Department




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Type extension questions
  1995-03-27  0:00       ` Norman H. Cohen
@ 1995-03-30  0:00         ` Cyrille Comar
  0 siblings, 0 replies; 12+ messages in thread
From: Cyrille Comar @ 1995-03-30  0:00 UTC (permalink / raw)


ncohen@watson.ibm.com (Norman H. Cohen) writes:
: In article <3l0frd$b9t@lang8.cs.nyu.edu>, comar@cs.nyu.edu (Cyrille Comar)
: writes: 
: |> koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) writes: 
: ...
: |> :                                                             What I
: |> : really want is private inheritance ala C++.
: |>
: |> Don't try to be too close to C++, this doesn't fit Ada's
: |> model. "Private inheritance" is meaningless in Ada since "Private" is
: |> a caracteristic of packages and inheritance a characteristic of types
: 
: No, there is a direct Ada analog to a C++ class with a private base
: class, namely a private type implemented as a tagged derived type: 
: 
:    package Base_Type_Package is
:       type Base_Type is tagged ...;
:       ...
:    end Base_Type_Package;
: 
:    with Base_Type_Package;
:    package Derived_Type_Package is
:       type Derived_Type is private;
:       procedure Some_Operation (X: in out Derived_Type);
:       ...
:    private
:       type Derived_Type is new Base_Type_Package.Base_Type with ...;
:    end Derived_Type_Package;
: 
: --
: Norman H. Cohen    ncohen@watson.ibm.com



No, This is NOT a direct analog! A private Child package of
Derived_Type_Package has full visibility over Drived_Type and
Base_Type and you CANNOT enforce private inheritance in this
context. Your statement is correct if and only if you are ready to
accept a non-sense rule such as 1 package = 1 class = 1 tagged type or
something like that.

I really think it is important to avoid the confusion between packages
which controls the privacy in Ada and C++ classes which also control
the provacy but are more related to tagged type than to packages...
-- 
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489





^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~1995-03-30  0:00 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1995-03-22  0:25 Type extension questions Harry Koehnemann
1995-03-22 12:01 ` Robb Nebbe
1995-03-23 22:05   ` Harry Koehnemann
1995-03-25  6:59     ` Cyrille Comar
1995-03-25  7:13     ` Cyrille Comar
1995-03-27  0:00       ` Norman H. Cohen
1995-03-30  0:00         ` Cyrille Comar
1995-03-27 17:29       ` Harry Koehnemann
1995-03-27 20:26         ` Robert I. Eachus
1995-03-29  0:00           ` Harry Koehnemann
1995-03-27 20:37         ` Kennel
1995-03-23 22:03 ` Tucker Taft

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