From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin C.Atkins To: 9fans@cse.psu.edu Subject: Re: [9fans] g++ Message-Id: <20030915130330.53d99a2b.martin@parvat.com> In-Reply-To: References: <20030914144757.30e9b14c.martin@parvat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Mon, 15 Sep 2003 13:03:30 +0530 Topicbox-Message-UUID: 3651f756-eacc-11e9-9e20-41e7f4b1d025 On Sun, 14 Sep 2003 08:53:26 -0400 Brantley Coile wrote: > On Sun, 14 Sep 2003 14:47:57 +0530, Martin C.Atkins wrote: > > > Looking back at your previous message, perhaps it is the > > "scope rules and silent actions associated with inheritance", in > > which case are there any "Object Oriented" languages that you think > > are OK? > > I'm not Charles, but I also answer. Sorry, I really meant: Hi Charles, Everyone, > > Have you seen Oberon-2? It is OO done well. I know of it. I suppose the thread that I was trying to pursue was that Charles' message implied that the problems he had with C++ are fundamental to the object-oriented approach (i.e. inheritance). What does Oberon-2 do that mitigates the complications of "silent actions associated with inheritance", for example? On this question - Charles, would the modification of the 'self' reference (so that it did not allow calls to overriding methods) address your problems? I've seen plenty of discussion (hype) over the last 20 years about the advantages of the object-oriented approach, but precious little analysis or discussion of the problems associated with it! In this light, much of the following thread has been interesting, especially the comments about generics, and polymorphism, but threads such as Rob's comment: > i agree. o-o is so easy to do by hand in the few cases it really > contributes to the design of software that it seems unimportant to > have languages centered on it, yet polymorphism is a genuine boon but >... really begin to address the question of whether object-oriented (whatever it means - that's another problem, but for now, maybe I mean specifically the inheritance aspects) might be a step too far for the understandable, maintainable construction of programs, and what might be the alternatives. As I touched on in my first message. I believe that better type-compatibility rules in conventional languages (based on interfaces, rather than construction) would be a step forward in promoting the "o-o is so easy to do by hand in the few cases..." part of Rob's message. The Plan9 compiler's 'anonymous substructures' extension was an interesting experiment in this direction. But what about making pointers to struct { int a; int b} and struct { int a; int b; int c} type compatible in the correct circumstances? This would provide support for much of the power of o-o, but would it also open the door to the abuses/difficulties? This discussion also reminds me of Sussman and Abelson's approach that the language should allow programming in the style appropriate to the problem, whether that style be o-o, logic, functional, etc. The problem in using different languages for each of these styles is that intercalling becomes difficult. The problem with using the same language is that no current (strongly-typed) language seems capable of (conveniently) supporting the whole range of styles. I want a compile-time strongly typed language for other, orthogonal but important, reasons. > > Brantley Coile > Martin -- Martin C. Atkins martin@mca-ltd.com Mission Critical Applications Ltd, U.K. http://www.mca-ltd.com{/,/martin}