Re: Ada 200X

["Robert I. Eachus" <rieachus@attbi.com>]

And838N@netscape.net wrote:

 > There was one other issue I came across when writing my first Linked
 > list in Ada.  There is no "this" keyword.  It didn't take long for me
 > to realize that a class in Ada is not at all like a class as I
 > understand from college (C++, Java).  The "flavor" of an Ada was C
 > struct like to me and required passing "my" instance as a parameter
 > to a procedure of function in a package so that I could use "this".

The feature that you are looking for is called an access discriminant. 
This allows an object to have a self reference, or more important, a 
reference to the containing object.  Unfortunately access discriminants 
usually break information hiding.  If you do use access discriminants to 
create linked lists, the linked list code can muck with the other 
fields, and worse, the code for the non-list related fields has to know 
it is part of an object in a list.

The alternative is to use mix-in style generics to create linked lists 
of objects.  This results in the list code knowing nothing about the 
properties of the objects in the list and the object code being 
independent of the list. Much better, especially when you want to work 
with heterogenous lists.

Which is better?  Wrong question.  Sometimes you need for an object to 
be able to pick itself up by the scruff of its neck.  Most of the time, 
you don't.

 > My view may be somewhat biased because I'm new to Ada but the idea of
 > an Ada class doesn't seem like a class to me at all.  It seems like
 > putting a bunch of C methods and a struct definition into a .c file
 > and compiling it and calling it a class.  There's obviously more to
 > Ada than that but I described how it "seemed" for someone trying to
 > move to Ada.

The thing that you are missing is that a class in Ada is more of a 
mathematical concept than a declarative object.  Declaring a tagged type 
in Ada, whether or not it is a derived type, creates a class.  However, 
there is no way to simply look at the code and see all the potential 
types that are members of the class.  The mechanics works so that units 
as they are compiled can create code that works with all members of the 
class.  However, in any compilation unit the visible operations of the 
class is a subset of all the operations (methods) for the class.

What seems even worse is that information hiding can result in a class 
having many methods/operations with the same name and parameter profile. 
  Which one you dispatch to depends on the visibility at the point of 
the call.  In practice this is not a problem at all, it is a fundamental 
principle of information hiding.  If those other definitions could 
magically appear and hide the ones you knew about, that would be bad. 
Instead the behavior of an object can be understood in terms of only 
what is visible at that point.  As you can guess from the first part of 
the message, not all objects know their own name (self).  And those that 
do may only know it in part of the scope where the object itself is visible.

 > My purpose for moving to Ada is all the hype about reducing the cost
 > of maintenance and the quicker development time.  I read a bunch of
 > articles on how Ada is superior to other languages because once you
 > learn it your development goes quicker and the end result requires
 > less maintenance.  Two key things if I want to play in a global
 > market against "inexpensive" programmers/engineering firms in places
 > like India.

You will find that the hype is not hype, it is real.  And information 
hiding is a fundamental part of the benefits.  The more you can reduce 
what a programmer needs to know about an object or value, the easier and 
more bug free code becomes.  The flip side is that to get the benefits, 
you have to ruthlessly limit what is visible to what is necessary. 
Again, this gets back to the "self" discussion and linked lists.  The 
benefit of having a linked list package which knows nothing about the 
contents of the list, and objects which can't know that they are 
contained in a list should be obvious.  But to get those benefits, you 
need to use a mix-in list type.