Re: [9fans] g++

[Martin C.Atkins <martin@parvat.com>]

On Sun, 14 Sep 2003 08:53:26 -0400 Brantley Coile <brantley@prepaynt.com> wrote:
> On Sun, 14 Sep 2003 14:47:57 +0530, Martin C.Atkins <martin@parvat.com> 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}