AdaFAQ

Why doesn't Ada use 'dot' notation for OO?

Contributors:
If you are used to the notion of an abstract data type, defined by a type and a set of operations, and then you decide you want to support extensibility of abstract data types, then you end up at something very much like Ada 95, Haskell, or CLOS, with the "operation(operand, operand, ...)" or "operand operand" or "object := operation(operand, operand,...)" syntax familiar from theoretical mathematics and logic. If you instead focus on updating objects as the primary operations of interest, then you end up with the . syntax. In some ways, the Ada 95 syntax is more sympathetic with the "value-oriented" (i.e. functional) way of thinking than the "object-oriented" (i.e. side-effecting) way of thinking. The net effect, in any case, is that you can more easily write in a "functional" style in Ada 95 where there is less use of heap-resident read/write objects, and more use of values (rather than objects) of an abstract type being passed around, assigned, declared, etc.

One interesting side note -- because Ada is a multi-tasking language, the objects that are designed to retain read/write global state need some kind of synchronization/protection. For such objects (tasks and protected objects), the object.operation(...) syntax is intentionally chosen, because there is clearly a special role played by the "target" task or protected object. By contrast, for value-oriented operations like set union, the symmetrical syntax of "union(set1, set2)" seems far more intuitive than "set1.union(set2)", and the symmetrical syntax is used for such operations in Ada.

(Tucker Taft)

Next | Table of Contents