Newsgroups: comp.object
Subject: Re: comparing object-oriented platforms
From: Des.Kenny@bbs.actrix.gen.nz
Date: Fri, 2 Oct 1992 04:43:13 GMT
Organization: Actrix Information Exchange
Keywords: Object, state, Eiffel 
Summary: Object state access in Eiffel

In article <TMB.92Oct1180516@arolla.idiap.ch> tmb@idiap.ch writes:
> In article <1992Sep30.031100.7446@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
> 
> >  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.
> > [...]
> >  In C++ in it is quite simple to violate this basic cornerstone of
> >  OO. In Eiffel it is totally impossible to violate it.
> 
> What you are arguing for is opacity. Opacity can be achieved in many
> programming languages, including C and C++, without even ever using
> any OO techniques. That is, you can define a datatype in C/C++ such
> that you are guaranteed that no user of that datatype manipulates it
> without going through the interface that has been provided by the
> author of the datatype.

  Yes I agree you CAN in many languages, some more easily than others.
  The difference between C++ and Eiffel is in Eiffel you MUST protect
  an object's state by its methods.

  If all programmers in industry were able to consistently develop
  software that followed good information hiding principles that
  very carefully controlled access to state variables, there would be
  no need for tools that forced such an approach. This would be an
  alternative development scenario. And quite legitimate and sensible
  it would be also.

  BUT the assumption that all programmers in industry are so well
  disciplined is sadly just not true. We have to face reality and
  accept the fact that many programmers in industry do need to be forced
  into the disciplines of information hiding by the tools they use.
  There has been quite adequately demonstrated over the last twenty
  years of industrial software development.

> 
> I agree very much with programming in terms of abstract datatypes.  I
> like opacity. I like modularity. I think those features should be
> supported by the language.
> 
> However, what Eiffel provides (in fact, forces upon the user) is far
> more specific and restrictive. Eiffel uses one particular scheme for
> naming and organizing operations and types (a particular form of
> classes), it uses one particular scheme for data-driven programming (a
> particular form of dynamic method dispatch), and it use a particular
> form of code reuse (inheritance). There are alternatives to these
> schemes.
  
  Yes Eiffel forces some restrictions in some areas, such as 
  object state access. Classes are also types as well.
  It has multiple inheritance for code reuse.
  It also allows client supplier relations for code reuse. 
  It also has generic types for code reuse. 
  It has polymorphism and dynamic binding for code reuse.
  The point is not each of these facilities alone it is the
  combination of all of them together that is important.
  
  Yes there are other ways to do these things. Many of these
  concepts are not new, some are quite old. But I happen to
  think that they have been packaged together very effectively
  in Eiffel. So that each of the capabilities complements the
  other. 

> 
> I don't follow the "OO philosophy", nor do I follow the "COBOL
> philosophy". I'm not a philosopher.

  We are all 'philosophers'.


> I want to write re-usable, safe,
> bug-free code in a minimum amount of time.
  Thus your 'philosophy'.

> You simply seem to be
> making the implicit assumption that OO (that is, OO Eiffel-style) is
> the only way to achieve that, and that anybody who doesn't follow that
> philosophy writes "spaghetti code", uses global variables, and
> violates data abstraction.

  No. There are probably some brilliant COBOL/FORTRAN/C/ASSEMBLER/etc
  programmers out there. They are probably the most disciplined
  brilliant software designers in the world. May be you are one
  of them. I don't know. 

  BUT , again, in industry we have to deal with reality. Many
  many programmers struggle to be good designers in ANY language.
  These are the one that need better tools to guide ( restrict)
  them. Unfortunately they are the majority and this is where
  the budgets are spent, for better or worse.

> No, indeed, no purely OO language satisfies me. However, the OO
> facilities that C++ provides are a useful enhancement to C, and the
> resulting language in its totality, including non-OO features such as
> templates, is a useful tool for getting work done, more useful then if
> those non-OO features were eliminated from the language.
 
  If by templates you mean generic types Eiffel not only has generic types
  it allows (optional) constrained generic types. A constrained generic type
  means that the type that is instantiated at run time is restricted
  to a set of types ( and their descendents). This seems quite sensible
  to me in some contexts.
   
  Genericity is not unique to OO , true. But genericity,multiple inheritance
  , polymorphism and dynamic binding, encapsulation,
  state access by method only, assertions,
  responsibility-driven exception handling etc are a combination of 
  capabilities that are available in Eiffel and I find them very useful
  in such a combination.

  --Des Kenny
    Objective Methods