Re: Is Ada an OO Language? (was => Re: polymophism)

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <Pine.GSO.3.95.961125130229.25064B-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:

   > This is not to suggest returning to the old days before we thought
   > about software in terms of objects.  It simply is a question about
   > the potential limitations inherent in our commonly accepted view
   > of software objects. Perhaps the notion of object is too small an
   > idea.  

   About a dozen years ago I was trying to explain to a new Ada
programmer what he wasn't doing right.  (It wasn't wrong just--not
right.)  I said something like:

   "The problem is that you are trying to model the solution, and you
should actually be modelling the problem domain."

   When what I had said sunk in, I excused my self to go make sure I
had it right.  (And for Ada I did.)

   The solutions (and the problems) are a moving target, but Ada
allows you to build--at very little implementation cost--models of the
domain in which you are working.  Once you have a good domain model,
many solutions can be stated--and coded--in a few lines.

   I just ran into the advantages of this again.  Some of the code I
wrote for the ADAR project used a model of picture strings that did
not agree with the final Ada 95 standard.  Fixing the code required
lots of effort to find out what needed to be changed--that part of the
standard is certainly not simple--and I worked on keeping it as simple
as possible.  However, most of the changes were one-liners that were
immediately obvious once I knew where to look, and whether or not
there was a bug.  (This is not to say I didn't find a couple of my own
bugs, but for the most part the effort was deciding whether a given
string was legal or not.)

   That code has two scanners and two parsers--one set for numeric
values, one for picture strings.  If I had not structured the code to
correspond to the problem domain models, it would have been almost
impossible to figure out where to look.

   I think the longest time between actually characterizing a problem
and putting my finger on the fix was about ten minutes.  I do have a
debug facility built in to the picture string parser, but I never even
used the debugger that supplied with the compiler.  (Characterizing
the bugs involved things like finding that the grammar rejected
pictures that had floating currency symbols using ##... but not $$...,
and had a sign but didn't have any digits after the decimal point.)

   Incidently, one of the functions has fourteen return statements.
Horrible design?  NO!  The spaghetti nature of the return code is
forced by the specification.  Given that the best thing to do is
reflect the problem space in the code.  If I need to add a fifteenth
case, it would be relatively easy.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...