Re: An observation of Ada (may offend)

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com
(R.A.L Williams) writes: 

|> b. No bit level manipulation (fixed in Ada95 but only for unsigned
|> ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

   function Sign_Bit (N: Integer) return Boolean is
   begin
      return N < 0;
   end Sign_Bit;

|> f. Undefined 'baggage' in the run-time system. OK, this is unavoidable
|> with a language like Ada, it makes me nervous with Eiffel and C++ as
|> well, but, so far, I haven't tried to use those languages in embedded
|> systems (got a C++ one coming up soon). Its not so much needing a
|> run-time system, its not knowing what's in it. This is largely a compiler
|> vendor issue, not a language issue. HCTBAEL
...
|> HCTBAEL = "How can this be an embedded language?"

Pragma Restrictions, which must be supported (in different ways) to
conform to the real-time or safety-critical annexes, addresses this
concern in Ada 95.

|> h. And a special one for Ada95: poor encapsulation of objects. I can
|> define a 'member function' for a class by including the class in the
|> parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
|> even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
|> other features of Ada go out of their way to force the programmer to
|> follow 'good practice' (sometimes a matter of opinion), this seems
|> very lax.

You can do this in C++ and Eiffel too.  The only difference is
notational.  In C++, an operation Op invoked as Obj1.Op(Obj2) can only be
written inside Obj1's class, but an operation Op invoked as Op(Obj1,Obj2)
or Obj2.Op(Obj1) can be written elsewhere.  In Ada, the call would be
written as Op(Obj1,Obj2) in each case.  Whatis important is that in Ada,
C++, and Eiffel, an operation manipulating a private component/member/
feature of a type/class can only occur logically within the defining
unit.

The purpose of encapsulation is not to restrict who can be a client of a
class, but to restrict who can manipulate its internal representation.
For example, given a private type for queues, the internal representation
of a queue can only be manipulated by calling abstract operations such as
Enqueue and Dequeue.  Nonetheless, it is possible outside of the defining
package to write an Append operation, moving all the contents of one
queue to the end of the other, by calling Dequeue with the first queue as
a parameter and Enqueue with the second queue as a parameter.  This is
not a violation of encapsulation.

If there is a weakness in Ada encapsulation, it has nothing to do with
parameter lists, but with the definition of "logically within the
defining unit".  Anyone can write a child package that is "logically
within the defining unit".  (Do-While Jones once called this the "Howard
Hughes effect": strangers claiming to be your heirs.)  Child units enjoy
access analogous to that permitted for C++ protected members in a
subclass of a definining class.  Thus the strongest degree of hiding that
Ada can provide is that of C++ "protected", not C++ "private".

One way to justify this is by thinking of the program library--er,
compilation environment--as a hypertext document with implicit links from
parent units to child units, reflecting the logical nesting of the child
units within the parent units.  Then writing a child unit is, in effect,
modifying the parent unit.  It is always possible in any language to
"break encapsulation" by modifying the defining unit!  Some development
environments may have access-control tools to restrict the ability to
modify certain units.  The proper extension of such tools to Ada 95 is
also to restrict the creation of children for such units.

--
Norman H. Cohen    ncohen@watson.ibm.com