ephraim@techunix.BITNET (Ephraim Silverberg) (12/17/87)
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
-------------------------------------------------------------------------------sdl@linus.UUCP (Steven D. Litvintchouk) (12/17/87)
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
cox@ppi.UUCP (Brad Cox) (12/24/87)
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
bertrand@hub.ucsb.edu (Bertrand Meyer) (12/26/87)
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-1006sdl@linus.UUCP (Steven D. Litvintchouk) (12/28/87)
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
sdl@MITRE-BEDFORD.ARPA (Litvintchouk) (12/28/87)
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
sdl@MITRE-BEDFORD.ARPA (Litvintchouk) (12/28/87)
> 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.
MFELDMAN@GWUVM.BITNET (Mike Feldman) (12/28/87)
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?
rich@devvax.JPL.NASA.GOV (Richard Pettit) (12/29/87)
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."
cjh@petsd.UUCP (Chris Henrich) (01/06/88)
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.
dee@linus.UUCP (David E. Emery) (01/07/88)
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
ks@tut.fi (Kari Syst{) (01/07/88)
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