Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!umich!samsung!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!thor!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.object Subject: Re: The essence of objects... Message-ID: Date: 23 Jul 90 11:54:49 GMT References: <1280@media01.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 86 In-reply-to: pkr@media01.UUCP's message of 10 Jul 90 08:10:13 GMT In article <1280@media01.UUCP> pkr@media01.UUCP (Peter Kriens) writes: But I still have problems explaining oops to people who have no prior experience. When I start talking about inheritance, dynamic binding they start to gaze and we both feel lost. Why is it so difficult to explain something which is so advantageous to use and which feels so right? How do I explain the essence of objects? I will give you some of my ideas, with a premise: all we know of OO programming is OO languages really. The first idea is that when structuring a program we have an implicit matrix that maps (function,datatype) -> implementation. OO programming is that style of programming in which you list the matrix by datatype and not by function or any other order, i.e. you assume that the diverse implementations that apply to the same datatype are fundamentally more related than the diverse implementations of an operator applied to different datatypes. The second, related, idea is that the principal tool of program design is decomposition, and that OO programming is that style of programming where you decompose not by function (FORTRAN), not by datatype and function (PASCAL), not by module (ADA), but by abstract data type. The first idea comes from some paper by Fabry on capability systems, the second from some article by Stroustrup on decomposition. As a general comment, why are these two things important? Not in themselves, but because we believe that selecting the proper program description and decomposition paradigms will enhance reuse of interface, semantics, implementation. Too bad that many OO practitioners have lost sight of this ultimate goal, and use fuzzily defined concepts like polymorphism or dynamic binding or inheritance (which are merely devices) without reference to such goal. More specifically I think that the two points of view given above on why we want to do OO programming reveal both strengths and weaknesses of the idea. For example, it is usually usually true that listing the (function,datatype) matrix by datatype is a good choice; concatenation of matrixes and lists require quite different implementations, while concatenation and cloning of lists have mostly similar implementations (but this is because the navigational part is usually small). It is also true that decomposition by ADT is usually, by the same token, more appropriate than the other forms, which either miss out one of the dimensions or are too unstructured. On the weakness side, it is apparent that programs are not just collections of ADTs, but also of "glue" logic, and that the real semantics of the program belong to this "glue" logic, which usually is a graph navigator (interpreter). Where the "glue" logic is prevalent on the data manipulation, maybe then fucntional decomposition is more appropriate for example. My own view of programming is that programs cannot be decomposed at every level with a single paradigm, like OO purports to do, but that you need *two* paradigms, that alternate, where you have a navigational sublayer, a driver that explores some overall data structure and calls upon one of a library of ADTs as the next layer to operate on part of the structure, or upon a lower level navigational component if the structure is many layered. It is especially difficult to use this model in OO programming, because for a number of reasons it is difficult in most OO schemes to express control abstraction and semantics that straddle ADT boundaries, i.e. the "glue" navigational code or driver. In other words, IMNHO it is the case that OO is nice to describe *libraries* of ADTs, but it is less apropriate to describe *programs*, especially if they have a strong navigational or control component. In practice only continuation passing (and maybe polymorphism) provide the required support for control abstraction. Too bad that they are arcane arts outside the advanced fringes of the Lisp community. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@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