Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.object Subject: Re: ADT vs. Objects Message-ID: Date: 18 Nov 90 16:30:16 GMT References: <1990Nov13.212012.3662@Neon.Stanford.EDU> <3187@mrsvr.UUCP> <1990Nov16.061612.14517@tukki.jyu.fi> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 73 Nntp-Posting-Host: teachk In-reply-to: sakkinen@tukki.jyu.fi's message of 16 Nov 90 06:16:12 GMT Posting-Front-End: GNU Emacs 18.55.4 of Thu Nov 23 1989 on athene (berkeley-unix) On 16 Nov 90 06:16:12 GMT, sakkinen@tukki.jyu.fi (Markku Sakkinen) said: sakkinen> In article sakkinen> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> On 14 Nov 90 16:18:52 GMT, chandra@mrsvr.UUCP (B. Chandramouli) pcg> said: chandra> You need inheritance provided by the language when you want to chandra> subclass from a class that is part of a standard class library chandra> provided by a vendor for which you have only the object code chandra> and not the source. pcg> Ahem. Really? I have ever more the impression that you have a very pcg> narrow definition of code sharing and reuse. In other words, the C/Fortran idea of code dharing and reuse. One for examples that excludes overloading, generics, etc... The assumption here is that the fairly tight coupling of reuse of interface and of implementation, as provided by inheritnace, is the only alternative. sakkinen> Narrow definition? I did not see any claim of inheritance sakkinen> being everything one needs for code sharing and reuse. Well, he is saying that his goal is reuse of implementation as object code, and that the only real technology for that is inheritance provided by language; this is indeed a narrow view. There are other technologies; for example dynamic linkers, library mechanisms a la Ada, etc... that solve the code reuse without source problems. Also, note that (as somebody else has already noted in this thread) you still need, in many current environments, to do reuse of interface in source. Instead, for example, Ada compilers are required to implement generics without the source, and, at least partially, also interface reuse (even if I do not like much how either feature is actually realized) without source ("WITH p; PACKAGE q is NEW p.r(FLOAT);"). sakkinen> tell how inheritance in this sense can be practically replaced sakkinen> by other means in commonly available environments. It cannot, because as I had observed elsewhere the basic code reuse technology in commonly available environments is the linker, and commonly available linker designs go back to the fifties, as they are based on static binding with component identification based on name alone. C++ 2.x uses the clever but sad trick of encoding type information in the name of a component to fool linkers out of the fifties in doing componenent resolution also on type ("type safe linkage" pah!). Better solutions can be readily imagined, and have been implemented, as long as commonly available linkers are thrown out of the window. Inheritance is not the solution to reuse of implementation in object form; better tools that support object form reuse directly are the solution, as the original poster said: From article <1990Nov13.212012.3662@Neon.Stanford.EDU>, by craig@Neon.Stanford.EDU (Craig D. Chambers): craig> Inheritance of implementation seems like something that could be moved craig> out of the core language and into the programming environment, where craig> more flexible and adaptive code sharing/automatic programming could be craig> done without cramming a lot of functionality into a language craig> mechanism. I would venture as far as saying that inheritance is not the solution to the reuse problem in general, and I seem to remember that you have a paper on this subject :-). -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk