From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: comparing object-oriented platforms
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 9 Oct 1992 19:53:02 GMT

In article <2047@snap> paj@uk.co.gec-mrc (Paul Johnson) writes:
>In article <1992Oct4.133146.964@ucc.su.OZ.AU>
>>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>>[Agrees with GC] Conversely, C++'s constructor/destructor scheme is
>>more powerful than Eiffel's more simplistic scheme.
>
>I don't understand what you mean by this.  The Eiffel creation system
>is as good as C++ (especially in Eiffel 3), and the C++ destructor
>business is simply there because it lacks GC.  

	It must have been advanced over OOSC, which has
Create and Clone only. Can you define arbitrary constructors
in Eiffel3? C++ destructors of course can do much more than
destroy the object, they can for example close a Window.
That would require an explicit call in Eiffel woudln't it?
But in C++ it is automatic when the object goes out of scope.

>BTW in ISE Eiffel you
>can arrange a routine to be called when an object is collected.  Its
>part of the MEMORY class (but it only works for full collections,
>unfortunately).
>
>>A proposed design, A++,
>>appears to me to be more advanced than the scheme presented
>>in OOSC, although because C++ is so complex cf. Eiffel
>>Eiffel might be able to optimise many of the assertions
>>away at compile time where C++ would struggle with aliasing
>>and other nasty problems.
>
>Can you tell us about this A++.  I don't recall hearing about it
>before.  I have looked at doing Eiffel-style assertions in C++, and it
>is not trivial.

	Indeed. "The Behaviour of C++ Classes", Marshal P Cline
(cline@sun.soe.clarkson.edu) and Doug Lea (dl@oswego.oswego.edu),
sorry I cant remember the ftp address, but I think its on 
sun@soe somewhere. The intention was to put in the assertions
as run-time checks, unless they could be optimised out by
a logic system, but it proved too hard to reason about C++,
so they gave up so I'm told. Eiffel should have an advantage
here, it is conceptually simpler to only have references and GC.

>
>[On C++]
>
>>The biggest advantage is that it provides a path for working
>>programmers to learn new and better techniques, and keep being
>>productive.  If they were already writing good ANSI C, the boss could
>>secretly switch the compiler to C++ and they main thing they'd notice
>>would be improved type checking and better diagnostics.
>
>If all you want from C++ is "a better C" then this is true.  However
>it is not true if you want to do OO programming.  As soon as you start
>using inheritance, particularly multiple inheritance, you find that
>C++ has major problems.  Take a look at the disambiguating rules in
>the ARM some time.

	I have read it many times. Eiffel, and all MI systems
have ambiguity problems, but Eiffel has a solution that works
and C++ has one that works sometimes. It is possible that
C++ will get a rename facility.
>
>>And even if they were superprogrammers and could learn
>>Eiffel and OO in one day, it would be difficult
>>to just rewrite a huge C project in Eiffel in 
>>the next 6 days. With C++, you wouldn't have to.
>
>Granted.  Legacies are always a problem when new technology comes
>along.

	Perhaps unfortunately, the best language will not
necessarily be the most successful. But then language design
is not merely an academic persuit, people actually use
programming languages to do work. (Including academics :-)

	But really, I dont see that Eiffel is that different to
C++. It has one major advantage---garbage collection and thus
no need for pointers (or values).

	(BTW: I like Eiffel! Wish I had a compiler)
>
>>I'm interested in some anecdotal evidence on Eiffel Use.
>>When I switched to C++, my pattern of programming changed
>>radically. Most programs, if they dont work the very first
>>time, work by the second or third time. By 'work',
>>I mean execute cleanly. So I do not spend much time
>>getting programs to run anymore. (Chasing bugs)
>
>Take a look at my paper in TOOLS 7 (p335).  It describes the progress
>of a project written in Eiffel.
>
>>On the other hand, I spend much much more time on design.
>>C++ classes are supersensitive to correct design, 
>>if I stuff up a class I may have to rework a good fraction
>>of the system. Once a class is heavily used (and reused),
>>it is very hard to change it's interface.
>
>This is very true.  The interface specification facilities in Eiffel
>are there because of this issue.  Without them you tend to find a
>"hidden" interface becoming important, as various bits of code take
>advantage of behaviour which is not in the actual spec.  In Eiffel one
>still has to guard against this, but it is much easier because the
>assertions make it clear who is responsible for each bit of behaviour.

	If you decide to reorganise a subsystem, change the way
those responsibilities are defined, and the relevant classes
are used elsehwere and so cant be modified, then you
have a rewrite on your hands. So you need to get it right first
time, and that quite hard. (In other words, you must
avoid opening a closed module, so you have to delay closing
the module till you're sure its designed properly... which
is hard to be sure about till you have used it)

	I sorely miss invariants, preconditions etc in C++.
(In fact I'm writing a preprocessor that will let me
put A++ assertions in as documentation, even if there
are no run-time tests that would be nice)


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.object,comp.lang.objective-c