What is the non-synchronized equivalent to a protected type in Ada?

Question

Ada has a construct called "protected types", where you have a collection of variables and subprograms associated with a type, and the subprograms have implicit synchronization. These types can be instantiated and each instance will have its own memory where the variables live. This looks a lot like the class/object duality in mainstream OOP languages such as C++ and Java, minus inheritance, plus mandatory implicit synchronization.

Is there an equivalent to this construct, minus the synchronization? If not, what's the rationale behind this design choice?

To be entirely clear, I'm aware that Ada supports different styles of OOP without any kind of synchronization. My question is about the specific style of OOP I mentioned - as it is one of the most common styles found in mainstream languages, and is indeed also present in Ada in some form.

To further clarify the question, which had been intentionally (and misguidedly) left open-ended, I am aware that the answer is "packages". But then, consider the following:

• We have packages, which are units containing variables and subprograms, of which several instances can be created
• We have types, which are enums or projections/mod of built-it types (I know this is a very approximate definition, specifics don't really matter here)
• We have protected types, which are... units containing variables and subprograms, of which several instances can be created. Plus, they have synchronization.

This begs the thought: why "protected types" and not "protected packages"? This thought is the origin of the present question.

Answer 1

OOP is a set of concepts in programming without any dependence in a particular syntax. According to the Ada 95 Rationale: "Type extension in Ada 95 builds upon the existing Ada 83 concept of a derived type. In Ada 83, a derived type inherited the operations of its parent and could add new operations; however, it was not possible to add new components to the type. The whole mechanism was thus somewhat static. By contrast, in Ada 95 a derived type can also be extended to add new components."

In Ada a type is a type, independently of it providing OOP features or not. Ada 95 provided extension on top of other POO features already provided by Ada 83 types. The advantage of that is that you can turn easily a non-tagged type to a tagged type, if you later need type-extension, without affecting current uses of the type. This also avoids introducing hidden features in the OOP syntax, like friend classes (types sharing the package), static members (global package variables), the implicit this, or const at the end of a method to indicate that this object is not modified, etc.

Why protected types do not follow this pattern? They probably follow that of Ada 83 task types, but the latter don't have a private part, so it is still inconsistent. The design probably chose syntax of task types as inspiration, but added private part for efficiency (that was the main concern: "protected types allows a more efficient implementation of standard problems of shared data access").

Answer 2

So this is an answer to the title of this question: "What is the non-synchronized equivalent to a protected type in Ada?"

I'm adding this mainly for people searching this question looking for the answer to the topic's title question.

Take a simple example protected type:

protected type My_Type is

    procedure Set_Value(Value : Integer);
    function Get_Value return Integer;
    
private

    The_Value : Integer := 0;
    
end My_Type;

protected body My_Type is

    procedure Set_Value(Value : Integer) is
    begin
        The_Value := Value;
    end Set_Value;
    
    function Get_Value return Integer is
    begin
        return The_Value;
    end Get_Value;
    
end My_Type;

The equivalent non synchronized version would be to use a record type (or a tagged record if you want type extension) within a package paired with the operations on that type:

package My_Types is 

    -- For type extension use:
    -- type My_Type is tagged private;
    type My_Type is private;
    procedure Set_Value(Self : in out My_Type; Value : Integer);
    function Get_Value(Self : My_Type) return Integer;
    
private

    -- For type extension use:
    -- type My_Type is tagged record
    type My_Type is record
        The_Value : Integer := 0;
    end record;
    
end My_Types;

package body My_Types is

    procedure Set_Value(Self : in out My_Type; Value : Integer) is
    begin
        Self.The_Value := Value;
    end Set_Value;
    
    function Get_Value(Self : My_Type) return Integer is
    begin
        return Self.The_Value;
    end Get_Value;
    -- Alternate syntax:
    -- function Get_Value(Self : My_Type) return Integer is (Self.The_Value);
    
end My_Types;

Operations declared within a package that operate on a type in the package before that type is frozen are "associated" to that type (Ada calls them primitive operations). This includes functions that return those types.

For the "why" each layout was chosen differently, I don't really know. It might be helpful to take a look at the bottom of the following page and look through all the comments/emails/discussions of the ARG (credit to Simon Wright for the initial link):

http://archive.adaic.com/standards/ada95.html

If I had to guess without fully reading those sections Simon pointed me to (I will get to reading them all the way through), I would wager it has to do with the fact that records existed as is before protected types existed and protected types were thought more of an extension of the tasking model, so they iterated on the task type layout for protected type. Some of what I did read(here and here) already led me to believe they ran into some existing issues (either technical or philosophical) trying to layout protected types more like records.

Note that protected types do not give the full set of "information hiding" capabilities as most programmers expect, such as public vs private member variables (only private for protected types).

Credit to Simon Wright for the links I provided