From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
Date: 30 Sep 92 22:48:12 GMT
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

Des.Kenny@bbs.actrix.gen.nz writes:
: In article <TMB.92Sep29101816@arolla.idiap.ch> tmb@idiap.ch writes:
: > In article <1992Sep28.024059.25761@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
: > 
: >                            But C++ is a poor compromise at best.
: > 			   It is not real OO.
: > 
: > I'm really glad that C++ is a compromise between OO and non-OO
: > facilities. If it weren't, it would be much less expressive and much
: > less useful.
: > 
:   You need to make up your mind. Do you want to use the OO approach
:   or not.

This is unnecessarily dogmatic.

: If you do then in my opinion Eiffel is the most advanced
:   OO language. 

Well, maybe "Eiffel is the most object-oriented advanced language".

:   If you want to allow free state access style programming that is a different
:   issue. The Eiffel approach is to separate these two paradigms.
:   In traditional procedural style programming you have global states
:   which are accesible from any module, a module can not protect itself
:   from the incursions of other modules. 
: 
:   The OO approach is quite different. Each object/module is responsible
:   for the access and management of its own state. No other object can
:   get in and alter its states without permission. At least this is the case
:   in Eiffel. It is not true in CLOS and it is only partially true in
:   Smalltalk, you may be surprised to hear ( a subclass may access the 
:   state of a parent class) and it is arbitray in C++.
: 
:   In C++ you have a confusion of these diametrically opposing state
:   management philosophies. Some variables may be global while others
:   may be protected by methods. This is not a clean state of affairs.

Real life isn't always clean.

The real question, does it help me write good programs?  Does it help
my successor change my programs?

Sometimes you need to change somebody's state.  If it can be done,
it will be done, but if your language is anal-retentive, you'll have to
fight it to do what needs to be done.

You'll end up either creating a useless dummy object, just so that you
can call one of its methods, even though the object itself has no meaning,
or you'll end up creating useless methods that you only use in one
place somewhere totally different in the code.  You end up creating
spurious new names and complexity that can only clutter up your overworked
and undercaffeinated brain. (:-))

I *hate* it when I have to fight the language to do something simple.
(For example, if you want to return multiple values in most langauges,
for example in C, you end up having to create a structure whose purpose
in life is only to encapsulate all the return values in a single bundle,
but which otherwise has no purpose.  That's needless confusion and
complexity).

:   It is a confusion of responsibility. The whole philosophy of OO
:   is to place responsibility for each module's state in the hands 
:   of the module itself. There is a new autonomy and independence
:   given to modules. They can get on with their own job without
:   worrying that other modules can come along and mess in their state
:   of affairs. 

I agree that this is often beneficial.
But why should this one thing be the cornerstone of modern programming?

I think there are other issues.  Such as making things clear, simple, and work.

: 
:   So we are not just talking about minor syntax issues.
:   This is a major change in th philosophy and politics of
:   software modules. You may not like this. You may think that
:   there are some areas of OO that are dubious, still under research
:   etc. Which I may even agree with you in some specific cases.
: 
:   But the central policy of OO is tha assignment of responsibility
:   of state management to each object/module and no other module should burgle
:   its way in to change states by avoiding method interfaces.
:   This is what OO is really all about. 
: 
:   In C++ in it is quite simple to violate this basic cornerstone of
:   OO. In Eiffel it is totally impossible to violate it.

The bigger problem with C++ is more the C problem, that pointers can point
anywhere, and trash anything.

: 
:   The Eiffel approach is better. If you want to mix modules from
:   these different paradigms, or other paradigms like logic programming
:   or some other approach, then you call such modules from Eiffel.
:   But they are treated as another world which this particular application has
:   a need to communicate with.
:  
:   So you can call C from Eiffel ( and Eiffel from C ) for example.
:   Such external modules are considered to be part of the implementation rather
:   than the specification of an Eiffel class. You may chose to replace an
:   external module with a new one,  a better algorithm for example. Such
:   an implementation change has no impact on the specification/interface of a
:   class at all. From a point of view of large scale systems such isolation
:   from localised change is a major improvement in the stability of an
:   industrial system. You can not guarantee such a robust evolution
:   of change with C++ because it is not a 100% OO. There is global data,
:   states can be altered by other modules without permission of the
:   owner of the state. It is a philosophical and political confusion.

Yes, but this is overblown.  What ends up happening is that you end
up creating methods that alter the such and such state. 
Then the problems just devolves into "Well who called that method when
i wasn't looking".  Same basic problem, but now it's been laundered into
something virutous by a function call.  BFD.

In sum, I think programming languages should help programmers first, and not
be a philosophical manifesto.  (Is this a subject-oriented language?)

By the way, I guess I must be somewhat of an Eiffel fan, because I hate
C++, and am getting more and more pleased with Sather.  I haven't yet
written a single kludge in it yet, but i'm sure the time will be coming
at some point.

:   Regards
:   --Des Kenny
:     Objective Methods Ltd

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
Newsgroups: comp.object