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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2ea02452876a15e1
X-Google-Attributes: gid103376,public
From: rogoff@sccm.Stanford.EDU (Brian Rogoff)
Subject: Re: Real OO
Date: 1996/03/29
Message-ID: <ROGOFF.96Mar29120640@sccm.Stanford.EDU>#1/1
X-Deja-AN: 144896061
references: <DoDLr7.JDB@world.std.com> <4if7s5$bfk@ra.nrl.navy.mil>
organization: /u/rogoff/.organization
reply-to: rogoff@sccm.stanford.edu
newsgroups: comp.lang.ada
Date: 1996-03-29T00:00:00+00:00
List-Id: <comp.lang.ada>

     Of course there is no inherent limitation in Ada. If one wanted to be 
     absolutely true to the tenets of OOP, one could do something like this:

     package Number is 
       type Base_Number is abstract tagged private;
       function "+" (L, R : Base_Number) return Base_Number is abstract;
	 -- also operators for "-", "*", ... etc.
     private
	type Base_Number is abstract tagged null record;
     end Number;

     <rest of example deleted for space>

	Before you exclaim, "Arghhhhhhh" let me suggest that there
	might be circumstances in which you really want to create your
	own very restricted variation of the arithmetic operators for
	the concrete types derived from this abstract class. In fact,
	this could be the foundation abstract class for the famous
	Fractions package, the Vector Arithmetic package, or several
	other packages that service non-standard number models.

	Furthermore, although we customarily use numbers defined in the
	Ada LRM, nothing prevents us from approaching number definitions
	in a more "pure" OOP mode.  I realize, such an approach will be rare, 
	but I can imagine safety-sensitive applications where it might make 
	sense to do something such as this.

	Richard Riehle
	adaworks@netcom.com

I think that the main concern that I would have with such an approach, 
i.e. representing numbers as tagged types, is the overhead of having a 
tag associated with each numeric item. If you define your "Rational" type 
this way, and then start manipulating Rational matrices, can you be 
reasonably sure that your Ada compiler will eliminate the tags if your 
Rational is not involved in runtime dispatching? Or will you get an 
M x N x sizeof(tag) overhead for every M x N RationalMatrix?

I think a better approach might be to use generic formal package parameters 
to create type signatures for the numeric types you create. It is a little 
syntactically heavy though, and I kind of wish there were a nicer way to do 
this sort of thing in Ada...

-- Brian