From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 28 Jun 93 08:47:00 GMT
From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!math.ohio-state.edu!howland
.reston.ans.net!xlink.net!news.dfn.de!scsing.switch.ch!epflnews!disuns2.epfl.ch
!lglsun!nebbe@ucbvax.Berkeley.EDU  (Robb Nebbe)
Subject: Re: Membership tests for tagged types
Message-ID: <1993Jun28.091935@lglsun.epfl.ch>
List-Id: <comp.lang.ada>

In article <mcook.741125871@fendahl.dev.cdx.mot.com>, mcook@fendahl.dev.cdx.mot
.com (Michael Cook) writes:
: stt@spock.camb.inmet.com (Tucker Taft) writes:
: 
: [...]
: >the general feeling was that a general OO principle
: >is that "case statements are harmful."
: 
: Hmm.  What's wrong with case statements?

There is nothing wrong with case statements from the OO point of view.
Where OO purists have a problem is when you use a discriminant record
and then implement the operations with case statements on the
discriminant.  This is more cleanly implemented through inheritance and
dispatching which makes the code clearer and more maintainable.
However, in Ada 83 we don't have full support for inheritance and no
support for dispatching so we are stuck with case statements and
discriminant records for the time being.

: 
: [...]
: >If I understand your example, it would be written as follows:
: 
: >   if X in A'Class then ...
: >   elsif X in B'Class then ...
: >   else ...
: >   end if;
: 
: >Admittedly not as readable as a "case" statement, but
: >it gets the job done and it keeps the language itself simpler.

I don't think there is really enough information in this example to be
really meaningful. It could be a case where one shouldn't even be using
the class attribute and operator overloading would handle everything
just fine. Or it could be better solved with inheritance and
dispatching.

Here is a case that might be interesting.

Given the type hierarchy

             Dog
              |
     ____________________
     |        |          |
                 
Big_Dog  Medium_Dog Little_Dog

and a stack of Dog'Class objects (a heterogenous stack of Big, Medium and
Little Dogs)

Suppose we want to sort the stack into three homogeneous stacks.

could we just write three insert procedures

   procedure Insert( The_Dog : Big_Dog);
   procedure Insert( The_Dog : Medium_Dog);
   procedure Insert( The_Dog : Little_Dog);
 
one for each stack and then write some sort of loop around
 
   Insert( The_Dog => Pop( The_Stack => Mixed_Dog_List ));
   
where Pop returns the Dog'Class object off the top of the stack?  Here
I would be hoping that the compiler could determine which insert to
call at runtime based on the type of the Dog'Class object.  However
Insert is not a primitive operation of the type Dog so I'm not at all
sure if this is possible.  The alternative would be either a case or
sequence of if statements along with membership tests or restructuring
the code to make Insert a primitive of Dog.

Robb