Re: Inheritance and Ada

Re: Inheritance and Ada

[Mike Feldman]

The discussion on inheritance has been very interesting from a technical
point of view. I am a bit concerned by a series of messages discussing
other languages that turn out to be commercials of the form

"...Ada does not allow X, but NewLang does, and oh, by the way, my
company produces NewLang..."

Several comments are pertinent here. I do not oppose discussions with
some commercial content. Info-Ada is the major on-line forum about the
language, and commercial information is useful information. I would
prefer to see the discussion a bit more limited to Ada. What does
disturb me, though, is that a number of months ago a budding and very
useful discussion on certain PC-oriented Ada compilers was ruthlessly
suppressed (indeed, the forum was shut down for a time!) with no
explanation except a veiled one suggesting "commercialism."

There have been a number of interesting and important developments in
the Ada/microcomputer world which I would like to see discussed but fear
would lead to another round of censorship. Frankly, as an educator
used to the free flow of information seen in forums on other languages
(C, Modula-2 in particular), I'd like to see this really be an info-ada
board. We who are not DoD contractors lack for useful information, and
it's hard to get to SIGAda meetings because they always seem to get
scheduled during our exam or registration weeks.

Well, friends, how would _you_ like it to be?

Re: Inheritance and Ada

[Richard Pettit]

In article <8712281731.AA27872@ajpo.sei.cmu.edu> MFELDMAN@GWUVM.BITNET (Mike Feldman) writes:
>
>Well, friends, how would _you_ like it to be?

Indeed, I think that it's the case that in the best interest of the people
who read this group, who are mostly professionals, that these sort of articles
should appear.

As noted, even though the articles in the mod2 news group tend to be a little
commercial, it gives those people who have bought the products that these
companies are advertising a chance for rebuttal. This allows both sides of
the sheet to be aired as it were.

I'd hate to think that one of the blows against Ada is from one of its own
constituents.

My vote here for less censorship.
-- 
rich@devvax.jpl.nasa.gov  "Generality up the ying yang. That's the way to go."

Inheritance and Ada

[Ephraim Silverberg]

I am an Ada beginner so please excuse me if this question is not too bright.
I am familiar with other object-oriented languages like C++ and Lisp Flavours
and wish to know if Ada supports inheritance as the other two do.  Please reply
by e-mail as this newsgroup doesn't arrive at our site.

-------------------------------------------------------------------------------

Ephraim Silverberg,
Faculty of Biomedical Engineering,
Israel Institute of Technology,
Haifa, Israel.

BITNET  :        ephraim@techunix
ARPANET :        ephraim%techunix.bitnet@cunyvm.cuny.edu
CSNET   :        ephraim%techunix.bitnet@relay.cs.net
UUCP    :        {ihnp4, allegra, rutgers}!psuvax1!techunix.bitnet!ephraim

-------------------------------------------------------------------------------

Re: Inheritance and Ada

[Steven D. Litvintchouk]

Posting-Front-End: GNU Emacs 18.47.1 of Sun Aug  2 1987 on linus (berkeley-unix)



> I am an Ada beginner so please excuse me if this question is not too
> bright.  I am familiar with other object-oriented languages like C++
> and Lisp Flavours and wish to know if Ada supports inheritance as the
> other two do.  Please reply by e-mail as this newsgroup doesn't arrive
> at our site.

I will both email you my answer and post it to this newsgroup:

Ada does *not* provide direct support for subclassing/inheritance in
the style of Smalltalk, Flavors, etc.  (And yes, I have found this to
be a major limitation of Ada.)

You can *simulate* inheritance in Ada, if you're willing to do some
extra work.  Two techniques are:
  
1.  Use derived types.  This works mostly when the subclass differs
from the parent class in such simple ways as range constraints.

2.  Use generics.  The generic formal parameters correspond to the
"inherited" scope (e.g. methods).  This rather general solution is
admittedly clumsy to program.  However, we at MITRE have worked out
what we believe is a reasonably complete solution to this, for
arbitrary semantic dependency networks of data types (including
cycles; i.e.  mutually recursive data types).

The important thing to watch out for is this:

Languages like Smalltalk & Flavors distinguish between clients (users)
that make instances of a class, and clients that define a subclass of
a class.  In the former case, the instances are true "black boxes";
i.e.  the instance variables are hidden; they can only be modified
indirectly via message sends.

In the latter case (inheritance), the subclass "sees" everything,
including the instance variables.  This makes it easy to add methods
to the subclass that manipulate the instance variables defined in the
parent class.  (Although there has been some discussion that this much
visibility in Smalltalk is overkill, and you could conceivably make do
with less.)

This distinction between those users of a class who make instances,
and those who make subclasses, does not exist in Ada.  Regardless of
whether you try to simulate inheritance via derived types, generics,
etc., you find that there is a conflict in Ada between encapsulation
and inheritance.

If you defined a "class" (abstract data type) in Ada, whose types are
private (i.e. instance variables are encapsulated or hidden), then if
you "inherit" this into a subclass, you have no way to get at the
instance variables of the parent class from the subclass.  On the
other hand, you could make the abstract data type definition of the
parent class visible.  Then its instance variables can be "inherited,"
but you have to violate encapsulation to accomplish this. So the
instance variables of each instance of the class are not protected
from manipulation by others.


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753
ARPA:  sdl@mitre-bedford.arpa
UUCP:  ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl

Re: Inheritance and Ada

[Brad Cox]

In article <19902@linus.UUCP>, sdl@linus.UUCP (Steven D. Litvintchouk) writes:
> 
> Ada does *not* provide direct support for subclassing/inheritance in
> the style of Smalltalk, Flavors, etc.  (And yes, I have found this to
> be a major limitation of Ada.)
> 
This is to thank Steve for his wonderfully clear explanation of Ada's
limitations as an object-oriented language, and to flame at bit at those
who are willing to live with those limitations rather than fixing them.

Ada also doesn't provide regular expression notation for writing lexical
analyzers, nor a BNF notation handy for writing parsers.

C doesn't provide these things either. But C lives in a culture that 
encourages its users to fix such limitations for example by providing 
preprocessors like lex and yacc. 

Ada lives in a culture that ruthlessly exterminates any thought of building
and using such tools.  THIS IS WRONG! DREADFULLY WRONG! DONT PUT UP WITH IT!

C also doesn't support object-oriented encapsulation and inheritance, but
we've fixed that with a tool that does, Objective-C.

I recently received a paper about a similar tool for Ada, InnovAda, to
be presented at the Technology Strategies conference. Call me or send
mail and I'll put you in touch with the author.
-- 
	Brad J. Cox; VP and Chief Technical Officer
	Productivity Products International
	75 Glen Road; Sandy Hook, CT 06482
	(203) 426 1875; ...yale!bunker!ppi!cox

Re: Inheritance and Ada

[Bertrand Meyer]

	I just saw some of the recent discussion on inheritance and genericity.
I am surprised none of the discussants quoted my article, ``Genericity
versus Inheritance'', which addresses precisely this topic. The paper
was published in the Proceedings of the first OOPSLA conference
(OOPSLA 86, Portland; SIGPLAN Notices, 21, 11, pp. 391-405). A revised
version is due for publication in the Journal of Pascal, Ada and Modula-2.
I would be surprised if Dr. Brad Cox did not know the original paper.

	The article explores the relationship between Ada-like generic modules
and inheritance as it exists in O-O languages. It shows the respective
benefits of both techniques and explains how they have been (cleanly,
I think) combined in the Eiffel language and environment.

	I was surprised to note that Dr. Cox mentioned Objective-C
as a language bringing a solution to the problem. In an untyped language
like Objective-C the notion of genericity does not even exist. Eiffel,
in contrast, is a fully typed language, where the type system is based
on (multiple) inheritance. Then genericity can be brought into the
picture, as in e.g.

		class STACK [T] ... end

which shows STACK to be parameterized by a type T. This way you can
declare, say, an entity

		is: STACK [INTEGER]

which is statically constrained to hold only integers. The call

		is.push ('A'),

for example, will be rejected by the compiler as incorrect
(the argument should have been an integer).
This does not prevent data structures from being polymorphic:
for example, if an entity is declared as

		fs: STACK [FIGURE]

then you may push onto the corresponding object a point,
a circle etc., assuming POINT, CIRCLE
etc. are descendant classes (in the sense of inheritance) of FIGURE.
However you may not push onto fs, say, an integer. This policy reconciles
flexibility and dynamic binding with the need for a proper control over
program reliability through static typing.

All this and more has been implemented efficiently and is used by
numerous organizations worldwide. There have been a number of
publications on Eiffel and a book is forthcoming
(Object-Oriented Software Construction, B. Meyer, Prentice-Hall,
February 1988).

		Bertrand Meyer
		Interactive Software Engineering, Inc.
		270 Storke Road, Suite 7
		Goleta, CA 93117
		(805) 685-1006

Re: Inheritance and Ada

[Steven D. Litvintchouk]

Posting-Front-End: GNU Emacs 18.47.1 of Sun Aug  2 1987 on linus (berkeley-unix)



In article <255@hub.ucsb.edu> bertrand@hub.ucsb.edu (Bertrand Meyer) writes:

> I am surprised none of the discussants quoted my article, ``Genericity
> versus Inheritance'', which addresses precisely this topic. The paper
> was published in the Proceedings of the first OOPSLA conference
> (OOPSLA 86, Portland; SIGPLAN Notices, 21, 11, pp. 391-405). A revised
> version is due for publication in the Journal of Pascal, Ada and Modula-2.
> 
> 	The article explores the relationship between Ada-like generic modules
> and inheritance as it exists in O-O languages. It shows the respective
> benefits of both techniques and explains how they have been (cleanly,
> I think) combined in the Eiffel language and environment.
> 

My apologies, I was at OOPSLA '86 and thought your paper was
excellent.  (and there have been other good papers on the subject as
well.)

> This does not prevent data structures from being polymorphic:
> for example, if an entity is declared as
> 
> 		fs: STACK [FIGURE]
> 
> then you may push onto the corresponding object a point,
> a circle etc., assuming POINT, CIRCLE
> etc. are descendant classes (in the sense of inheritance) of FIGURE.
> However you may not push onto fs, say, an integer....

Actually, attempting to simulate this kind of polymorphism in Ada is
even clumsier than your paper portrayed it.  As you pointed out, you do
end up having to define variant record types (whose variants include
all the polymorphic subclasses) and other case analyses all over the
place.  

Even worse, however, Ada does not let you instantiate the (generic)
STACK package with an unconstrained variant record type, if the
package requires the type to be constrained (as is often the case).
Thus in Ada, I find I am continually forced to play this game of
instantiating the generic with an access (pointer) type to the variant
record type.  Not only is this clumsy, but it requires you to use
allocators ("new") to create the instances of the record type, opening
up all the performance issues of using dynamic allocation in embedded
computer systems software.

Sadly, you are often forced to use access types in Ada, even when
you're not particularly interested in dynamic storage, but just to get
around some of the quirks of Ada's type model.  Another example:  you
can't instantiate a generic with an incomplete type.  So you end up
having to fake it by instantiating the generic with an access type
that points to the incomplete type, and you can guess the rest....


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753
ARPA:  sdl@mitre-bedford.arpa
UUCP:  ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl

Inheritance and Ada

[Litvintchouk]

> This is to thank Steve for his wonderfully clear explanation of Ada's
> limitations as an object-oriented language, and to flame at bit at those
> who are willing to live with those limitations rather than fixing them.
> 
> C also doesn't support object-oriented encapsulation and inheritance, but
> we've fixed that with a tool that does, Objective-C.
> 
> I recently received a paper about a similar tool for Ada, InnovAda, to
> be presented at the Technology Strategies conference. Call me or send
> mail and I'll put you in touch with the author.
> -- 
> 	Brad J. Cox; VP and Chief Technical Officer
> 	Productivity Products International
> 	75 Glen Road; Sandy Hook, CT 06482
> 	(203) 426 1875; ...yale!bunker!ppi!cox

1.  Brad, I am interested in hearing more about your Ada tool.  Please
put me in touch with the right people.  (Actually, I would have
guessed that an "Objective-Ada" would have been *much* harder than an
"Objective-C," due to Ada's lack of access types to subprograms, its
strong typing and encapsulation models, etc.)

2.  However, from the little you've said about it, it still doesn't
sound like a solution, but a way to live with Ada's lack of explicit
support for such object-oriented programming (OOP) techniques as
inheritance and delegation.  I hope you'll agree with me that a cure
is still preferable to a crutch.

I believe it is both reasonable and desirable to explore ways to add
explicit support for OOP to the Ada language, say by 1993.  (The
language does come up for review every five years, and this time there
is a technically enlightened, and growing, Ada user community that is
aware of recent advances in computer science.)  I see no reason why
this would "break" the Ada language; ref. such languages/projects as
Owl, Eiffel and Actra for potential solutions.  Perhaps somebody at
the Software Engineering Institute should be looking into this (hint,
hint; any of you SEI guys/gals got your ears on?).


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730
(617)271-7753

ARPA:  sdl@mitre-bedford.arpa
UUCP:  ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl

	"Those who will be able to conquer software will be able to
	 conquer the world."  -- Tadahiro Sekimoto, president, NEC Corp.

Re: Inheritance and Ada

[Chris Henrich]

In article <1673@ppi.UUCP> cox@ppi.UUCP writes:
>
>Ada lives in a culture that ruthlessly exterminates any thought of building
>and using such tools.  [as lex and yacc].
This, if true, is a fault of the Ada culture not of the language.
Is it true?  My experience in the Ada culture has been that we have a
lot of work to do, and fun projects like pre-processors have to
compete with bread-and-butter projects.  

An Ada tool that worked like yacc, and put out tables for the guidance
of a driver program (presumably written in Ada), would not be met with
ruthless hostility.

Regards,
Chris

--
Full-Name:  Christopher J. Henrich
UUCP:       ...!hjuxa!petsd!cjh
US Mail:    MS 313; Concurrent Computer Corporation;
            106 Apple St; Tinton Falls, NJ 07724
Phone:      (201) 758-7288
Concurrent Computer Corporation is a Perkin-Elmer company.

Re: Inheritance and Ada

[David E. Emery]

Posting-Front-End: GNU Emacs 18.47.1 of Sun Aug  2 1987 on faron (berkeley-unix)



There are at least 2 implementations of YACC for Ada.  One was done in
Finland, and described at a SIGAda a while ago.  The other is from
U.C. Irvine (I think).  The result of the latter tool is a package
with the appropriate routines made visible, and the tables and such in
the package body.  

I do not see what the lack of a pre-processor has to do with YACC and
LEX.  There is nothing that prevents someone from building a
pre-processor for Ada.  YACC is not a pre-processor in the same sense
that the C pre-processor is.  

On the other hand, the more traditional uses of the C pre-processor
includes things that are included in the Ada language, including
visibility (#include vs with), constants (#define FOO 15 vs foo :
constant := 15), and in-line procedures, doable in Ada using either
pragma inline, or generics.

Rather, I would say that the Ada 'culture' substitues the semantics of
the language for the textual substitution provided by a pre-processor.
Given the choice between compiler-checked language semantics, and 
pre-processor substitutions, I think the former makes a lot more
sense.

				dave emery
				emery@mitre-bedford.arpa

Re: Inheritance and Ada

[Kari Syst{]

In article <1165@petsd.UUCP> cjh@petsd.UUCP (C. J. Henrich) writes:
>In article <1673@ppi.UUCP> cox@ppi.UUCP writes:
>>
>>Ada lives in a culture that ruthlessly exterminates any thought of building
>>and using such tools.  [as lex and yacc].
...
>An Ada tool that worked like yacc, and put out tables for the guidance
>of a driver program (presumably written in Ada), would not be met with
>ruthless hostility.

I don't know if yacc-like tool belongs to Ada-culture or not, but
I have an Ada-yacc called YACCA.  This tools has been used to implement
some simple tools.  I have been rather happy with that tool.
I don't see why this tool is not suitable for Ada programming.
The emitted parser is an Ada-package (object in OOD).

BTW: This tool was among the tools we offered for testing.  The offer
     was announced in this news-group last summer (maybe June).


-- 
Kari Systa      ks@tut.fi (ks@tut.UUCP, systa@fintuta.bitnet)
Tampere Univ. Technology/Computer Systems Laboratory           Phone
Po. Box. 527, SF-33101 Tampere                           work: +358 31 162702
Finland                                                  home: +358 31 177412