Large Scale OO Development (was Re: C/C++ knocks the ....)

[donh@syd.csa.com.au (Don Harrison)]

Tucker Taft wrote:

:Matt Kennel (kennel@msr.epm.ornl.gov) wrote:
:: ...
:: As for Ada, I'm not yet fully convinced abou the package vs 
:: type thing.  C++ might be ugly because you can have all sorts of
:: elements outside classes, but in Eiffel you cannot.
:
:: Eiffel intentionally makes the unit of namespace and of type
:: the same. 
:
:: The question is, do the benefits of having them completely separate
:: make up for the extra work and complexity of having to double the
:: number of 'mental units' in most idiomatic programs.  (and without
:: MI you have to go a bit further) 
:
:: Yes, Ada has them on orthogonal axes.  Eiffel only has "one axis"
:: but it may empirically be along the major princpal component with
:: only a small deviation in other directions. 
:
:On the other hand, various Eiffel implementations have felt the
:need to add yet another language on top for doing "configuration"
:of large systems (I think it is called "GRACE"?).

Eiffel (as you would be aware) has been purposefully designed as a 'minimalist'
OO language. In this approach, the minimum required mechanisms are included in
the language proper but where possible, functionality is defined in standard
library classes and by reusing them to define other standard classes. To preserve
the purity (generality) of code, configuration information and compiler directives
are segregated into the ACE (Assembly of Classes in Eiffel) file. The contents are 
described in LACE (Language for ...) which follows an Eiffel-like syntax.

So, the real definition of the language is the core language + standard classes
+ LACE. Since each is simple to comprehend (and the core language and LACE are
similar), it takes very little effort to get a handle on Eiffel.

The advantages of this approach are several:

1) The core language is kept as simple as possible meaning that it is easy to
   learn and there are few concepts that the developer must grasp leaving him
   free to channel mental energy into abstractions.

2) The language definition itself employs reuse (both of classes and mechanisms).

3) Software text is not cluttered with information not inherent to the abstractions
   but specifying how the program is executed (eg. configuration information,
   compiler directives etc.).

This approach contrasts with that of Ada in which the core language is comparitively
complex because most functionality has been included in the core language. (The
use of Annexes in Ada 95 is a step in the right direction but it's like shutting
the gate after the horse has bolted.

Note that the complexity of Ada means that the developer has to devote excessive
mental energy to language details which ought to be applied to creating suitable 
abstractions. Minimalist languages win hands down on this score.

:                                                             This seems
:to indicate that programmers have a need to deal with larger groupings
:than that represented by a single class.  Although one could conceivably
:just create larger and larger classes, at some point the model of a "type"
:breaks down, whereas the notion of a package scales nicely to the
:notion of a subsystem, as in Ada 95.

Why should the encapsulation solely via classes break down for large systems?
I don't see why you can't (with well designed frameworks of classes) continue
reusing classes ad nauseum. Encapsulation using classes should cause no greater
impediment to creating higher level abstractions than encapsulation using packages.
If anyone can convince me otherwise, I'm happy to be educated.

:It is interesting to note that Java has the notion 
:of "package" for defining groups of classes.  This seems 
:like a reasonable compromise, though it still loses out on some of the
:other advantages of defining abstractions using a package rather than a
:class, such as symmetry of parameters in binary operations, and elimination
:of the pesky "once" or "static" qualifiers of Eiffel/C++/Java that are
:needed to turn a "component" of a type into a component of a module.

Attributes are not changed from being components of types to components of modules
through the use of 'once' functions. They are already components of modules because
the type IS the module. Their status is simply changed from being unique to each
instance to being shared by all instances (class attributes rather than instance
attributes). I'm not aware of any difficulties with this approach, so 'pesky' may
not be an appropriate epithet :-).

:-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
:Intermetrics, Inc.  Cambridge, MA  USA

Don.