CODEWITHSUNDEEP
adaencapsulation
Albatros23
Albatros23

Reputation: 331

Are Child Packages safe in ADA?

I am very new to ADA language and, during my learning process, I have been seeing a lot of examples which uses this ADA functionality. It seems to me that it could be useful only for unit testing in order to being able to test the private types and methods of the parent package, but I don't see any advantage for coding in such way, it seems that breaks encapsulation.

Is it a good practice to use them apart from unit testing?

Upvotes: 3

Views: 207

Answers (3)

egilhh
egilhh

Reputation: 6430

You can take a look at this presentation given at FOSDEM 2018, discussing (private) packages and enforcing safety:

https://archive.fosdem.org/2018/schedule/event/ada_safety/

Upvotes: 3

Jeffrey R. Carter
Jeffrey R. Carter

Reputation: 3358

Child packages exist to allow programming by extension, but as implemented they also provide a way to bypass the information hiding that pkgs are supposed to enforce.

While it can be convenient to design a hierarchy of pkgs sharing some hidden information, programming by extension is generally a poor idea that emphasizes ease of writing over ease of reading, and coding over software engineering. You might be interested in the article "Breaking the Ada Privacy Act", available here.

Upvotes: 1

Frédéric Praca
Frédéric Praca

Reputation: 1641

Child packages can be seen as an extension for their parent.

It can be used, for example, to provide functionalities that are not directly linked to your base package.

The typical example is the Input-Output package.

Imagine the following package :

package Temperature is

    type Kelvin_Temp is private;
    type Celsius_Temp is private;
    
    function build (temp : Positive) return Kelvin_Temp;
    function build (temp : Integer) return Celsius_Temp;

    function to_celsius (temp : in Kelvin_Temp) return Celsius_Temp;
    
    function to_kelvin (temp : in Celsius_Temp) return Kelvin_Temp;
    
  private
    type Kelvin_Temp is 0.0 .. 10_000.0;
    type Celsius_Temp is -273.0 .. 10_000.0;
end Temperature;

This package provides basic operations directly linked to the types defined.

What if you want to extend it to provide I/O in text format ? You can decide to put operations inside the Temperature package but if you want to add other types of I/O such as database I/O, you will have a lot of functions that are not directly linked to your types inside the same file.

You can define

package Temperature.Text_IO is

    procedure Put(temp : Celsius_Temp);

    procedure Put(temp : Kelvin_Temp);

end Temperature.Text_IO;

and

package Temperature.Database_IO is

   procedure insert (Temp : in Celsius_Temp);

   procedure insert (Temp : in Kelvin_Temp);

end Temperature.Database_IO;

That's exactly what is done with IO in the standard library

From an encapsulation point of view, your private types will remain private outside of the package hierarchy so you don't break encapsulation.

Upvotes: 6

Related Questions