Rationale behind Ada encapsulation of dynamically dispatching operations (primitives)

Question

In Ada, Primitive operations of a type T can only be defined in the package where T is defined. For example, if a Vehicules package defines Car and Bike tagged record, both inheriting a common Vehicle abstract tagged type, then all operations than can dispatch on the class-wide Vehicle'Class type must be defined in this Vehicles package.

Let's say that you do not want to add primitive operations: you do not have the permission to edit the source file, or you do not want to clutter the package with unrelated features.

Then, you cannot define operations in other packages that implicitely dispatches on type Vehicle'Class. For example, you may want to serialize vehicles (define a Vehicles_XML package with a To_Xml dispatching function) or display them as UI elements (define a Vehicles_GTK package with Get_Label, Get_Icon, ... dispatching functions), etc. The only way to perform dynamic dispatch is to write the code explicitely; for example, inside Vechicle_XML:

if V in Car'Class then
   return Car_XML (Car (V));
else
   if V in Bike'Class then
      return Bike_XML (Bike (V));
   else
      raise Constraint_Error 
         with "Vehicle_XML is only defined for Car and Bike."
end if;

(And a Visitor pattern defined in Vehicles and used elsewhere would work, of course, but that still requires the same kind of explicit dispatching code. edit in fact, no, but there is still some boilerplate code to write)

My question is then:

is there a reason why operations dynamically dispatching on T are restricted to be defined in the defining package of T?

Is this intentional? Is there some historical reasons behind this?

Thanks

EDIT:

Thanks for the current answers: basically, it seems that it is a matter of language implementation (freezing rules/virtual tables).

I agree that compilers are developped incrementally over time and that not all features fit nicely in an existing tool. As such, isolating dispatching operators in a unique package seems to be a decision mostly guided by existing implementations than by language design. Other languages outside of the C++/Java family provide dynamic dispatch without such requirement (e.g. OCaml, Lisp (CLOS); if that matters, those are also compiled languages, or more precisely, language for which compilers exist).

When I asked this question, I wanted to know if there were more fundamental reasons, at language specification level, behind this part of Ada specifications (otherwise, does it really mean that the specification assumes/enforces a particular implementation of dynamic disapatch?)

Ideally, I am looking for an authoritative source, like a rationale or guideline section in Reference Manuals, or any kind of archived discussion about this specific part of the language.

I would inquire about the possibility of adding a Visitor pattern using Ada-2005 Interfaces instead of requiring more primitive operations in the classes themselves. This is not an answer but hopefully it will inspire one (or a coherent reason why it can't work!) from someone more experienced in using interfaces. — user_1818839
@brian The Visitor pattern is a good workaround: (i) define a visitor interface in Vehicles (ii) defines the Visit procedures that dispatch on vehicle types and takes a visitor v as a second argument; each procedure calls v.Visit_XXX (where XXX varies for each known derived type) and (iii) implement derived visitor types in other packages (Vehicle_XML_Visitor, ...). I think I don't enjoy writing visitor patterns again and again, though :-) — coredump
I was looking for ways to write it once as an Interface and use it again and again. The nearest I can come up with is for the instantiation to include Vehicle as a record component. Ugly but might get the job done. I think a short "Introduction to the best ways to implement GoF Design Patterns it Ada 2005/2012" would be useful... — user_1818839
@brian Honestly, I don't see how to achieve it (even with generic packages), because a Visitor typically must define Visit_XXX functions that depends on the actual type being visited. How would you use the record component? — coredump

ajb ajb · Accepted Answer · 2014-02-24T16:39:37

I can think of several reasons:

(1) Your example has Car and Bike defined in the same package, both derived from Vehicles. However, that's not the "normal" use case, in my experience; it's more common to define each derived type in its own package. (Which I think is close to how "classes" are used in other compiled languages.) And note also that it's not uncommon to define new derived types afterwards. That's one of the whole points of object-oriented programming, to facilitate reuse; and it's a good thing if, when designing a new feature, you can find some existing type that you can derive from, and reuse its features.

So suppose you have your Vehicles package that defines Vehicle, Car, and Bike. Now in some other package V2, you want to define a new dispatching operation on a Vehicle. For this to work, you have to provide the overriding operations for Car and Bike, with their bodies; and assuming you are not allowed to modify Vehicles, then the language designers have to decide where the bodies of the new operation have to be. Presumably, you'd have to write them in V2. (One consequence is that the body that you write in V2 would not have access to the private part of Vehicles, and therefore it couldn't access implementation details of Car or Bike; so you could only write the body of that operation if terms of already-defined operations.) So then the question is: does V2 need to provide operations for all types that are derived from Vehicle? What about types derived from Vehicle that don't become part of the final program (maybe they're derived to be used in someone else's project)? What about types derived from Vehicle that haven't yet been defined (see preceding paragraph)? In theory, I suppose this could be made to work by checking everything at link time. However, that would be a major paradigm change for the language. It's not something that could be easily. (It's pretty common, by the way, for programmers to think "it would be nice to add feature X to a language, and it shouldn't be too hard because X is simple to talk about", without realizing just what a vast impact such a "simple" feature would have.)

(2) A practical reason has to do with how dispatching is implemented. Typically, it's done with a vector of procedure/function pointers. (I don't know for sure what the exact implementation is in all cases, but I think this is basically the case for every Ada compiler as well as for C++ and Java compilers, and probably C#.) What this means is that when you define a tagged type (or a class, in other languages), the compiler will set up a vector of pointers, and based on how many operations are defined for the type, say N, it will reserve slots 1..N in the vector for the addresses of the subprograms. If a type is derived from that type and defines overriding subprograms, the derived type gets its own vector, where slots 1..N will be pointers to the actual overriding subprograms. Then, when calling a dispatching subprogram, a program can look up the address in some known slot index assigned to that subprogram, and it will jump to the correct address depending on the object's actual type. If a derived type defines new primitive subprograms, new slots are assigned N+1..N₂, and types derived from that could define new subprograms that get slots N₂+1..N₃, and so on.

Adding new dispatching subprograms to Vehicle would interfere with this. Since new types have been derived from Vehicle, you can't insert a new area into the vector after N, because code has already been generated that assumes the slots starting at N+1 have been assigned to new operations derived for derived types. And since we may not know all the types that have been derived from Vehicle and we don't know what other types will be derived from Vehicle in the future and how many new operations will be defined for them, it's hard to pick some other location in the vector that could be used for the new operations. Again, this could be done if all of the slot assignment were deferred until link time, but that would be a major paradigm change, again.

To be honest, I can think of other ways to make this work, by adding new operations not in the "main" dispatch vector but in an auxiliary one; dispatching would probably require a search for the correct vector (perhaps using an ID assigned to the package that defines the new operations). Also, adding interface types to Ada 2005 has already complicated the simple vector implementation somewhat. But I do think this (i.e. it doesn't fit into the model) is one reason why the ability to add new dispatching operations like you suggest isn't present in Ada (or in any other compiled language that I know of).

Rationale behind Ada encapsulation of dynamically dispatching operations (primitives)

3 Answers