From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,df854b5838c3e14
X-Google-Attributes: gid109fba,public
X-Google-Thread: 1014db,df854b5838c3e14
X-Google-Attributes: gid1014db,public
X-Google-Thread: 103376,df854b5838c3e14
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: C/C++ knocks the ....
Date: 1996/02/19
Message-ID: <EACHUS.96Feb19143218@spectre.mitre.org>#1/1
X-Deja-AN: 140323446
references: <00001a73+00002504@msn.com> <4etcmm$lpd@nova.dimensional.com>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
Date: 1996-02-19T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <4g6hg8$f4j@ux1.lmu.edu> Ray Toal <rtoal@eecs.lmu.edu> writes:

  > Norman Cohen just posted a really good article on this topic a few
  > days ago and I won't repeat it here.  It should at least "convince"
  > people that separating package and type is a solid design decision
  > and not a hack to maintain upward compatibility with Ada 83.

  > Having programmed in Smalltalk and C++ before Ada 95, I admit I had
  > to look twice at the Ada approach because I was so USED TO confusing
  > class with module.  But taking a few minutes to get used to Ada's
  > approach I like it better.

    There are many people who start out with a "dogmatic" approach to
ADTs in Ada, limiting them to one per package.  But after a while you
ask why this type and that type appear in the same package
specification, you get some mumbling about "the $%^*&* language makes
it too difficult to put them in different packages."  A few months
later you see cogent comments for ADTs in the same package explaining
why it was done that way, and lots of what I prefer to call "helper"
type declarations that have no explanation.  (And don't need any.)

    For example, assume that your (private) ADT has several associated
flags.  You can (and often should) have one inquiry function for each
flag.  But the boolean flags may really indicate that the ADT is in
one of, say, five states.  Best in that case is to define an
enumeration type in the same package and have a single inquiry
function, and a single procedure to set the state if that is
appropriate.

    Other cases where "helper" types appear is when there are arrays,
lists, names, etc. as properties of the main ADT and the ONLY use of
these types is as state of the primary ADT.

--

					Robert I. Eachus

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