Re: Real OO

[adaworks@netcom.com (AdaWorks)]

Robert A Duff (bobduff@world.std.com) wrote:

: In article <4if7s5$bfk@ra.nrl.navy.mil>,
: Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
: >I figured that much. But how it this a limitation?

: It's a limitation by comparison with a "pure" OO language, in which
: every built-in data type, including things like integers, is a class,
: and you can do all the OOP-ish things with them.  I didn't say this
: limitation is important.  This thread started as a discussion of various
: differences between Ada and Eiffel, and this is one such difference.

  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;


  Then create concrete number packages for each kind of number. For
  example, 

     private
        type Int_16 is range -2**16 .. 2**16 -1;
        type Integer_16 is new Base_Number with record
           Value : Int_16;
        end record;


     or later,

     private
        type R_16 is new Float range ...;
        type Real16 is new Base_Number with record
            Value : R_16;
        end record;

     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
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112