Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.object Subject: Re: The Emperor Strikes Back Message-ID: Date: 16 Mar 91 14:34:04 GMT References: <1991Mar8.061042.5578@tukki.jyu.fi> <1991Mar11.062302.18142@tukki.jyu.fi> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 73 Nntp-Posting-Host: aberdb In-reply-to: sakkinen@tukki.jyu.fi's message of 11 Mar 91 06:23:02 GMT On 11 Mar 91 06:23:02 GMT, sakkinen@tukki.jyu.fi (Markku Sakkinen) said: sakkinen> By the way, it is useful that some people like you try to make sakkinen> established concepts of OOP questionable. On this I thank you, but I try to question established *misconceptions* of OOP, which usually arise from familiarity with Smalltalk or other narrowly defined systems. sakkinen> 1. I agree with you that it is unnecessary confusion to speak about sakkinen> "message passing" in Smalltalk and similar languages (I have even sakkinen> said that in a published paper). Alleluiah! Your published paper is not the first to make this point, but its contribution is not irrelevant. sakkinen> 2. I have also tried to minimise the role of inheritance and sakkinen> to explain it by other concepts. Another excellent contirbution! sakkinen> However, I don't quite agree with your opinion that sakkinen> inheritance is totally superfluous and perhaps harmful (isn't sakkinen> that in essence what you have said?). No, I say that what we really want is unrestricted (when meaningful) mixing and matching of interfaces and implementations (and specifications) among themselves and with each other. What currently passes for "inheritance" is really prefixing, and prefixing is a very restrictive algebra for interfaces and implementations. If you call "inheritance", contrarily to what I perceive to be the common usage, as the ability to mix and match interfaces and implementations (and specifications) _in general_, then I am all for "inheritance". I remember Betrand Meyer in his classic book first introducing the idea that we want to do mix and match as I like it, and then slamming in Eiffel which really only has (whether multiple or deferred) prefixing. A big disappointment. sakkinen> 3. I don't buy your view of objects being simply values. That sakkinen> is evidently the view of functional programming (perhaps logic sakkinen> programming too), but it simply does not fit all programming sakkinen> paradigms. One of my problems is that at times I am too elliptic. I did not quite say that objects are *just* values. What I said that if you define as the set of all naturals to which a given group of function implementations is meaningfully appliable, then the notion of becomes quite redundant, or else misleading. The reason, let's try to be clearer, is that what currently passes for as belonging to a is really a particular, often Smalltalk-centric, implementation of . CLOS is the obvious (if incomplete) counterexample, even if one just uses its standard metaobject protocol. I am a bit reluctant to continue a discussion on my idea of because it is so unconventional and thus requires a lot of explanation, but I will try to mention some related work. I have recently noticed a definition of that is in some way analogous, in the language Emerald. There a is the set of all values to which a given set of functions *interfaces* is meaningfully appliable. I disagree about interfaces, because it is a purely syntactic requirement that creates what are IMNHO meaningless type equivalence classes; I prefer a semantics based partitioning. Yet the similarity is intriguing. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk