rkr@g.g.oswego.edu (Rajendra K Raj) (11/18/90)
Craig D. Chambers (craig@Neon.Stanford.EDU) writes: > Inheritance of implementation seems like something that could be moved > out of the core language and into the programming environment, where > more flexible and adaptive code sharing/automatic programming could be > done without cramming a lot of functionality into a language > mechanism. > -- Craig Chambers Yes, I agree. Both language simplicity and flexibility of code reuse do require that mundane issues such as implementation inheritance or any other mechanisms for code reuse be moved into the programming environment. For a longer discussion, I'll refer you to our paper at last year's ECOOP, where we suggested one strategy for doing this (Raj & Levy, A compositional model for software reuse, ECOOP 89, July 89). On the other hand, B. Chandramouli (chandra@mrsvr.UUCP) writes: > Replacing Inheritance with Code sharing/Reuse facilities provided > by the programming environment will work only for cases where you > have access to the source code. You need inheritance provided by > the language when you want to subclass from a class that > is part of a standard class library provided by a vendor for which > you have only the object code and not the source. > chandra If inheritance (of implementations) is available in the programming environment, there would be (or ought to be) a scheme for having the kind of black box inheritance alluded to by Chandra. If such a scheme exists (and it will if you believe in implementation inheritance), then the programming language still doesn't have to be made ugly to handle this. Of course, there could be other reasons for including implementation inheritance in a programming language, although I haven't seen any as yet :-) - R. K. Raj rkr@g.oswego.edu Department of Computer Science State University of New York Oswego, NY 13126