Re: Help me to chose between ADA 95 and C++

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <3859abde_3@news1.prserv.net>,
	"Matthew Heaney" <matthew_heaney@acm.org> wrote:

>In article <83b8il$i5k$1@nntp4.atl.mindspring.net> , Richard D Riehle 
><laoXhai@ix.netcom.com>  wrote:
>
>> I am sure Matt Heaney will have some good things to say about this too.
>
>Well, I have some things to say, but I'm not sure they qualify as
>"good."

Whenever you say something like that, I know we are in for some
controversial commentary from you.  :-)
>
>My advice is not to declare a numeric type as private.  In a sense, the
>type is already private, so you're hiding a type whose representation is
>already hidden.

In general this is true.  From time to time it might be useful to
expand or contract the exported behavior for a particular numeric
type.  For example, I saw a design not long ago with this declaration,

       type Counter is private;
       function Initialize return Counter;
       function Increment return Counter;
       function Decrement return Counter;

where the full defintion was a integer type. The designer intended to 
prevent any operations on Counter except increment and decrement. For
this application, that was a reasonable approach and eliminated any of
the complications associated with a client doing more arithmetic than
necessary.  I can think of other circumstances where it would be
useful to hide the actual type definition and export a restricted set
of operations, or a special set of operations.  Moreover, it might be
useful to expand the set of exceptions for that type and add pre- and
post- conditions in the implementation of some operator/operation.  


>For example, the floating point declaration

   [ snip ]

I understand your argument for simply using the available numeric
types as defined in the language.  This is usually appropriate. Now
and then it is appropriate to take the design a little further with
private types.  Not always.  But it is nice that we can do this when
it is appropriate.

Your example, as follows would be overkill if one where doing nothing
but parroting all the primitive operations.  
>package P is
>
>  type T is private;
>  <primitive ops>
>
>private
>
>  type Rep is digits 8;
>  type T is new Rep;
>
>end P;

Suppose, however, that we want to do a little more than that.  
Suppose the Divide operation is modified as (contrived example):

    function "/"(L , R : T) return T is
        Result : T;
    begin
       if R = Zero then ...          -- raise some exception?
       elsif some-other-condition    -- raise some other exception 
       elsif even-another-condition  -- raise even-another-exception
       else
          Result := Division-operation
       end if;
       if Result is-in-some condition -- raise post-condition-exception
           -- potentially more tests
       else
          return Result;
       end if;
     end "*";
              
I fully understand the problems with this example, but I also recognize
that, in the absence of exportable pre- and post-conditions in Ada, we
have few options but to check for these within the code itself.  Under
these circumstances, I might want to write my own operators to ensure
conformity with rules that cannot be described through simple range
constraints.
>
>I agree that, for abstract data types, it's better to use a function
>instead of a deferred constant, but for a different reason.  The problem
>with constants is that they aren't inherited during a derivation.
>Functions, because they're primitive operations, are inherited.

I agree that this is an additional problem.  Deferred constants seem
to violate many of the principles of object-oriented programming.

I think we are once again in agreement on most points.  

Richard Riehle