I used to do that until I heard that the ANSI C standard will state
that external identifiers should not be equal in the first six
characters. Maybe POSIX says something else. I don't plan to port
my code to anything else than POSIX (and maybe PC-DOS, if I have to).

I also label each identifier with two to four characters that indentifies
a package. For example, the functions in my package for handling double-
linked lists in C has functions like "dlst_create_list" and
"dlst_next_item".
--
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50  Fax: +46 (0)758-197 20

Everyone involved in this discussion should get their hands on a copy
of Bertrand Meyer's book _Object-Oriented Software Construction_, Prentice-
Hall, 1988.  The design philosophy being discussed sounds virtually
identical to Meyer's exposition of the object-oriented design method.

Briefly, Meyer's summary of object-oriented design is as follows:

        Ask not what the system does, ask what it does it to.

In other words, the most important characteristic of the system is NOT
its overall "intended function".  The most important description of the
system is in terms of the objects, the data, that is manipulated by the
system.

This is more akin to bottom-up design than to top-down design, for sure,
although the emphasis is slightly different.

The typical top-down design spec is functionally oriented; i.e. "We want
the system to Do This, and in order to Do It, it'll have to do this, and
this, and this..." etc., etc.  When you change your mind about what you
want it to Do, you're hosed.  Object-oriented style avoids this, by focusing
the design effort on the structure of the data to be handled, rather than
on the design of the whole system.  A proper object-oriented design is
inherently modular, and seldom needs a complete revision; the modules are
organized in a network rather than in a hierarchical tree, which means
changes to the net can be made without affecting the whole system; whereas
if you need to change the root of a top-down tree, you're hosed.

Exactly.  Your objects were general enough to be free from a specific
system.  This is reusability, and Meyer talks about how to get it.  A lot.

You should definitely go out and take a look at this book.  One of Eiffel's
(Meyer's language) main selling points is its reusable object library,
with everything from arrays to hash tables to an Xwindows library already
coded.  (According to reports, lexical analysis and (someday) concurrency
libraries will be available too.)  Sounds right up your alley!

Rob Jellinghaus                | "Next time you see a lie being spread or a


{everyone}!decvax!yale!robertj |     -- K. Eric Drexler, _Engines of Creation_

    I'd suggest Booch's coverage of object-oriented design in
    "Software Components with Ada" instead; Meyer's book comes
    bound up with a rather flaky programming language.

    Ada has far more reuseable ADTs already coded.  I'm coding a concurrent
    ADT right now, in fact.  Vendors such as EVB, lib systems, Wizard Software,
    and so on, have entire catalogs of Ada components you can buy right off the
    shelf, and Ada's rigorous standardization ensures that they'll compile
    anywhere.  Booch's other book, "Software Engineering with Ada" is also
    worth reading, and I think it also contains something on object-oriented
    design.  ("Software Components" is more of an advanced text)

    Also, one can obtain a magtape copy of the Ada Software Repository from

        MACA
        Attn: Janet Mckellar
        P.O. Drawer 100 - Bldg T148
        White Sands Missile Rang, NM  88002

    It fills up an entire magtape at 6250 bpi in tar format, and costs
    essentially nothing; all they need is your magtape and enough postage
    to get it back to you.

    The Ada Information Clearinghouse Newsletter periodically summarizes major
    Ada software libraries and systems; it's free, and you can get on the
    mailing list by sending a postcard to

        Ada Information Clearinghouse
        c/o IIT Research Institute
        4600 Forbes Blvd., Second Floor
        Lanham, MD  20706-4312

    Also, the recent issue of ACM SIGADA Ada Letters contains several
    interesting articles on ADT design and object-oriented programming.  

    comp.sw.components Mailing List administrator

I don't want to start an Ada vs. Eiffel debate, but the view that
Eiffel is a flaky language is something Bill Wolfe have to stand for
himself.

What I like to stress is: Ada is *not* an object-oriented language.
I used to think that, but there are just to much missing. Particulary
inheritance and dynamic typing. And although this is a trivial fact to
realise, it still seems necessary that from time to time make a reminder
about this. Due to Gary Booch and others it is easy for the casual
reader to get the impression that Ada <=> object-oriented programming.

But it's true that Ada is better for applying object-oriented strategies
than most other "conventional" languages.

As for bottom-up vs. top-down, Meyer explains this very well in his
book, and it's certainly applicable to the recent discussion. One
drawback with top-down I haven't seen well covered, is the big risk
that you never see that two leaves are the same, or see it too late,
so you get the same code in two places. (Or even worse, you should
have two identical pieces of code, but in fact they are different.)
  The project I'm in right now was designed top-down, if it was designed
at all. (It's a real mess, but don't blame me I came in too late.)
And it is a clear mistake. OK, there is a set of library routines
for low-level objects like formatting routines and simple database
accesses. But very little for handling of high-order objects like
account statements and other application specific things. I have
tried to introduce it, but when you need more than a day for it,
you get in conflict with the time schedule, whichh of course give
no place for "luxury" like that.
--
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.

IMHO, these ideas were more clearly expressed by people like
Parnas and Liskov back in the 70's.  For instance:

  D. Parnas, "On the criteria to be used in decomposing systems into
      modules," CACM, v15, Dec. 1972.

and more recently:

  B. Liskov and J. Guttag, _Abstraction_and_Specification_in_Program_
      _Development_, MIT Press and McGraw Hill, 1986.

Of course, the phrases "information hiding" and "ADT" don't sound
as high-tech as "object-oriented" :-)  (Comments about polymorphism
and inheritance unnecessary, and flames to /dev/null.).

John Baugh
--

    I quote from ACM SIGADA Ada Letters, March/April 1989, Volume IX,
    Number 2, Page 10:

      Software Productivity Solutions, Inc., has announced a new product,
      Classic-Ada (tm), which allows Ada software developers to use
      inheritance and dynamic binding in object-oriented Ada designs.
      The product runs on VAX/VMS and Sun/Unix systems.  For more
      information, contact:

         (407) 984-3370       Ms. Lois Valley
                              Vice President, Marketing
                              Software Productivity Solutions, Inc.
                              P.O. Box 361697
                              Melbourne, FL  32936-1697

   I stand by my statement regarding Eiffel's flakiness.  Obviously
   it's just my opinion, and others may differ, but I think it's a
   very well-founded opinion.

Do you mean that the language design is flakey, or that an
implementation is flakey?  If the former, what is flakey about it?
--

Univ. of Ariz. Dept. of Comp. Sci.      {allegra,cmcl2}!arizona!mike
Tucson, AZ  85721                       (602)621-2858

   [Karl Nyberg e-mailed me some information regarding my recent
    article, which I believe to be of general interest...]  

Organization: Grebyn Corporation
Phone: +1 703 281 2104

That's pretty good.  You only missed about another half dozen to ten
vendors.

   [Editor's note: I did say "and so on"...]

About ten other people also provide this service.  Differing formats are
supported by others for varying fees.  Folks on the arpanet can get it via
anonymous FTP.

As does my newsletter and recent book.  In case you missed the Jan/Feb Ada
Letters issue in which a draft of this review was printed:

==================================================================

Ada: Sources and Resources, 1989 Edition
  by Karl A. Nyberg

A Capsule Review by Dave Emery

At one time or another, most of us have served as "resource people"
for our companies on Ada.  Ada: Sources and Resources serves as a
single point for answering most of those non-technical "I have an Ada
question" phone calls that we seem to get.  Karl Nyberg has collected
information on vendors, organizations, publications and conferences,
and other related sources of Ada information, and placed it all into a
single volume.

The book starts off with a capsule history (presented chronologically)
of the Ada program.  This is particularly useful for documenting the
order of events in the history of Ada. (Which came first, the ACVC
contract or the Preliminary Ada reference manual?)  The remaining
chapters cover compiler vendors, software tool vendors, groups and
organizations (both government and private), publications, electronic
services, consultants and trainers, conferences, professional
recruiters, books and finally a glossary of terms and acronyms.  Each
chapter covers the material alphabetically, with extensive
cross-referencing.

The best entries in the book include historical information on the
vendor or organization, as well as information on the product or
service provided.  The entries always include a point of contact.
Some entries are not as complete as others, and this lack of
consistency is one of the book's few shortcomings.

In his forward, Bob Mathis compares the book to a well-stocked
Rolodex.  This book has a tremendous advantage over a Rolodex, namely
the comprehensive indexes.  There are separate indexes for names of
individuals (points of contact), "items" (proper names, such as ACEC
and VADS), vendors, and organizations.  It would be nice if there
were an index to compilers and tools by computer, to answer questions
like "What tools run on a Sun?"

This is a valuable book.  I had a pre-publication draft that saved me
a lot of time going through back issues of Ada Letters and sales
brochures to find the name of a particular vendor or organizational
contact.  It deserves a place right next to your telephone, either to
answer questions, or to call someone to get an answer.

==================================================================

   [I have deleted Karl's standard advertising blurb]

P. O. Box 497                         {decuac,haven}!grebyn!karl
Vienna, VA 22183-0497                               703-281-2194

We agree the components are desirable but a modular design should get you
there quickly too.   By breaking the system into smaller pieces with each
piece providing some well defined and more manageable part of the system,
the components should emerge.  Not only for the objects, but for the software
tools as well.  

Yes I have too.  I've taken a parser out of a 100,000 line compiler
and it wasn't pleasant.  I couldn't just take out the parser because
it was inextricable tied to the scanner and some semantics (typechecking)
was performed there too.  This undoubtable was due to efficiency reasons
and not top-down design.  If on the other hand the design had taken
reusable software tools into account the parser, scanner, and type system
would be separate entities with each providing a well defined interface.
It would be infeasible to reuse or add another scanner and much effort went
into taking the pieces out to the point where they were reusable.  They
finally did provide reusable components, the parser (and type-system)
generated an idl file representing the parsed functions and was used
immediately by two applications.  Someone recently asked to use the
parser/type-system and since yyparse (the parser) was modified to return
an object representing all the parsed declarations before passing them
to idl routines for output, he had exactly what he wanted in no time.
With just a little foresight on the part of the compiler designers and
with a greater priority given to software reuse the front-end of the
compiler would have provided the "software ecstasy" sought.  Of course,
Adts would have added greater potential for reuse of the data structures
involved but the tools were important too.

For projects which are not large, I think design will correspond
to recognizing the objects and major software components of the system,
and probably informal coding.  This isn't a major effort and can force
recognizing all issues involved very early.  For large projects, design and
implementation should be separate.

Aren't prototypes usually top-down and provide a skeletal framework to show
users so they can decide if the software is what they want, with each
function possibly stubbed out to provide simple or no service?   Or maybe
just a fast implementation to show the bottom level is even possible, but
I don't see what prototypability has to do with top-down design, to verify
the designs correctness?  I think prototyping can show the validity of a
"correct design", in other words top-down design with the benefit of
prototyping.

Good design will keep the low-level routines from knowing too much,
top-down or otherwise.  Just keep this in mind and you're SIL:-)

But with a modular design (top-down within modules) the tools are
functionally separate and they should not know they are a compiler, just
what their well defined function is to provide and an interface to meet.
I think keeping separate functionality separate is something thats really
important regardless of whether the encapsulation comes through packages,
processes, or whatever.  The same applies to objects, even when designed
top-down the lower level implementation of the Adt should be based on
components which are as generic as possible, I don't see how providing the
implementation calls for non-generic units since the recursive application
of good design will call for modular and generic components which are used
to implement the object.  I can see that if a designer throws away all
design principles after identifying the top level object he could end up
with an unstructured, data-structure oriented, special purpose implementation
but that should be easy to avoid.

Bob Hathaway

I strongly agree, most other conventional languages are data-structure
oriented and not Adt/object oriented in programming constructs or
methodology.

Could you elaborate on this, does he advocate top-down, bottom-up, ???
I haven't read Meyer's book.  

Bob Hathaway

Lest anyone get the wrong impression about Classic-Ada, let me
clarify: The Classic-Ada language is *not* legal Ada.  It is a unique
dialect, which consists of Ada extended (nicely) with a new
construct--the class--with inheritance and dynamic binding.

SPS, Inc., is to be commended for attempting to improve Ada's support for
object oriented programming.  But the resulting Classic-Ada language
is not legal Ada.  Classic-Ada programs must be put thru SPS'
translator to generate legal Ada.

Mr. Sommarskog is quite correct.  Ada lacks any specific mechanism for
defining relationships among classes; the Classic-Ada language
provides just this mechanism.  

Eiffel does manage to provide inheritance in a reasonably
strongly-typed framework.  In their zeal to facilitate object-oriented
programming, SPS added both inheritance and dynamic binding to
Classic-Ada.  Was dynamic binding necessary?  It seems to entirely
defeat the safety and reliability that was a goal of Ada.

I believe that Eiffel tries to provide both separate compilation and
generics, just like Ada.  And, just like Ada, I would suspect that the
early Eiffel compilers will have "teething problems."  (At OOPSLA '88,
I recall that several Eiffel users reported problems with the Eiffel
library manager; a real case of deja vu for us veteran Ada
programmers.)

Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753

UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl

        "Those who will be able to conquer software will be able to
         conquer the world."  -- Tadahiro Sekimoto, president, NEC Corp.

From what I was able to gather at OOPSLA '88, the current Eiffel
*implementations* are indeed flaky, but no more so than was any Ada
compiler developed prior to 1985.

I am extremely interested in finding out whether Eiffel compilers do a
better job compiling Eiffel generics, than Ada compilers do compiling
Ada generics.  I remain disappointed in how poorly Ada generics are
implemented by some Ada compilers.

Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753

UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl

        "Those who will be able to conquer software will be able to
         conquer the world."  -- Tadahiro Sekimoto, president, NEC Corp.