I have created an Ada class whose implementation has become quite large. I have a multiple body only methods that I would like move to a separate file for maintainability/readability purposes.
My understanding with Ada95 Separates is that you can only have one method per file. I have about 20 methods I want to separate but it is undesirable to me to create 20 separate files for this functions.
To separate the code I was thinking I could create a child package. Then the parent body could call the child class.
Q.1 In Ada, Is it wrong/undesirable for a Parent Body unit to depend on a child Unit?
EDIT: The above question is too vague and any answer would be subjective.
Q.2 How can I divide my code into separate files without creating an over abundance of files?
In fact you can have separate bodies for packages, protected and task types, as well as subprograms.
So you could say
package Large is
procedure A;
procedure B;
end Large;
package body Large is
package Implementation is
procedure A;
procedure B;
end Implementation;
package body Implementation is separate;
procedure A renames Implementation.A;
procedure B renames Implementation.B;
end Large;
with Ada.Text_IO; use Ada.Text_IO;
separate (Large)
package body Implementation is
procedure A is
begin
Put_Line ("large.implementation.a");
end A;
procedure B is
begin
Put_Line ("large.implementation.b");
end B;
end Implementation;
and to check
with Large;
procedure Check_Separate_Implementation is
begin
Large.A;
Large.B;
end Check_Separate_Implementation;
Equally, you could have Implementation as a child package:
private package Large.Implementation is
procedure A;
procedure B;
end Large.Implementation;
with Large.Implementation;
package body Large is
procedure A renames Implementation.A;
procedure B renames Implementation.B;
end Large;
The only difference I can see is that other child packages of Large would be able to see Implementation in the child package version but not in the separate version.
The Program Structure section of the Ada Style Guide (2005 edition) strongly prefers use of child packages rather than subunits, and says (in answer to your style question)
In preference to nesting in a package body, use a private child and with it to the parent body.
but, as you might expect, opinions will differ on this. You could read the Rationale section of the Guide and see how it fits your particular situation.
About the "correctness" of having a body (not a spec, you would get a circular dependency) depending on a child package, I use that all the time and I find it very convenient, especially to implement some complex data structure/service used internally by my package. The Ada Style guide (2005) agrees with me when it says
Use child packages to implement a subsystem
I guess this is your case too.
Related
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?
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.
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/
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.
I'm a former Java developer, using Oracle's SQL-Developer to create Oracle "packages."
Oracle's websites indicate that it's possible to create an Oracle "package" in which some objects (variables, functions, procedures) are accessible "outside" the scope of the package, while others are only accessible "inside" the package.
I.e., I'm trying to do something like this (pseudocode!), which intentionally but superficially resembles Java.
So, I'm asking, "How does one implement functionality that is similar to (java's) PUBLIC and PRIVATE in an Oracle PL SQL package"? ("See 'Oracle keyword' is enough to point me in the right direction.)
Thanks in advance!
CREATE PACKAGE a
// header
**PUBLIC** NUMBER nVisibleOutside := 1;
**PRIVATE** NUMBER nNOTVisibleOutside := 14922016;
PUBLIC PROCEDURE pVisibleOutside ();
PUBLIC FUNCTION fNOTVisibleOutside();
/* other stuff */
// body
/* actual code of pVisibleOutside and fNOTVisibleOutside(); */
END a;
Oracle uses a package specification and package body. Effectively, the specification defines all of the procedures/functions/variables/etc that you want to be accessible by other areas of code (for example, another package). The body then contains definitions of other procedures and functions that are "private" and also the logic behind the definitions in your package specification.
The example that you have provided above would go as follows:
CREATE OR REPLACE PACKAGE XX_EXAMPLE_PACKAGE AS
-- Variable that is visible to any code
n_visible_outside NUMBER := 1;
-- Procedure that is visible to any code
PROCEDURE p_visible_outside ( );
END XX_PACKAGE_SPECIFICATION;
/
CREATE OR REPLACE PACKAGE BODY XX_EXAMPLE_PACKAGE AS
-- A variable that is visible to the whole package body but not
-- to external code
v_dummy VARCHAR2(100);
-- Procedure visible to any code through the specification
PROCEDURE p_visible_outside AS
-- declaring a variable that is only visible to this procedure
n_not_visible_outside NUMBER := 14922016;
BEGIN
-- Logic
END p_visible_outside;
-- Function not visible outside as not declared in specification
-- can be accessed by code within this package
FUNCTION f_not_visible_outside RETURN BOOLEAN IS
--Logic
END f_not_visible_outside;
END;
/
You could then call the "visible" procedure in this way from another package:
XX_EXAMPLE_PACKAGE.p_visible_outside;
And, likewise, you can call the "visible" global variable in this way from another package:
-- You could use this in your code as say, a parameter
XX_EXAMPLE_PACKAGE.n_visible_outside;
-- You could assign the value to another variable in your code
v_dummy := XX_EXAMPLE_PACKAGE.n_visible_outside;
As a beginner it isn't as important to follow development standards, however, in the future you should. Hopefully, you have some local development standards however, you could probably find some Oracle PL/SQL standards somewhere on google.
Somewhat embarassed to ask this, but I know it's for the best. I've been programming in Ada for many years now, and understand nearly every part of the language fluently. However, I've never seemed able to wrap my head around T'Class. To borrow from others, can someone "explain it like I'm five?".
Edit: I bought it just to have, but contained within is a great description of, and example use of, T'Class; I refer to “Software Construction and Data Structures with Ada 95” by Michael B. Feldman.
If you start with
package P1 is
type T is tagged private;
procedure Method (Self : T);
end P1;
package P2 is
procedure Proc (Self : T); -- not a primitive
procedure Proc2 (Self : T'Class);
end P2;
In the case of Proc, you are telling the compiler that the parameter should always be considered precisely as of type T (remember that a tagged type is always passed by reference, so the actual type could be derived from T of course, you would not lose the extra data). In particular, that means that within the body of Proc, all calls to Method will be exactly calls to P1.Method, never a call to an overriding Method.
In the case of Proc2, you are telling the compiler that you do not know the exact type statically, so it will need to insert extra code to resolve things at run time. A call to Method, within the body of Proc2, could be call to P1.Method, or to another overriding Method.
Basically: with 'Class, things are resolved at runtime.
Well, if you were five, I would say that T'Class represents the whole family of T.
By family, we mean children and grand-children and grand-grand-children.
As you're not five, it means that this special type represents every tagged type which is in the inheritance tree of T. This way, if you use this type as a parameter, you can use every parameter which has T as ancestor directly or not.
For more information, you can read the wikibooks on this.
I'm a fairly new Ada programmer. I have read the book by Barnes (twice I might add) and even managed to write a fair terminal program in Ada. My main language is C++ though.
I am currently wondering if there is a way to "protect" subroutine calls in Ada, perhaps in Ada 2012 (of which I know basically nothing). Let me explain what I mean (although in C++ terms).
Suppose you have a class Secret like this:
class Secret
{
private:
int secret_int;
public:
Set_Secret_Value( int i );
}
Now this is the usual stuff, dont expose secret_int, manipulate it only through access functions. However, the problem is that anybody with access to an object of type Secret can manipulate the value, whether that particular code section is supposed to do it or not. So the danger of rogue altering of secret_int has been reduced to anybody altering secret_int through the permitted functions, even if it happens in a code section that's not supposed to manipulate it.
To remedy that I came up with the following construct
class Secret
{
friend class Secret_Interface;
private:
int secret_int;
Set_Secret_Value( int i );
Super_Secret_Function();
};
class Secret_Interface
{
friend class Client;
private:
static Set_Secret_Value( Secret &rc_secret_object, int i )
{
rc_secret_object.Set_Secret( i );
}
};
class Client
{
Some_Function()
{
...
Secret_Interface::Set_Secret_Value( c_object, some-value );
...
}
}
Now the class Secret_Interface can determine which other classes can use it's private functions and by doing so, indirectly, the functions of class Secret that are exposed to Secret_Interface. This way class Secret still has private functions that can not be called by anybody outside the class, for instance function Super_Secret_Function().
Well I was wondering if anything of this sort is possible in Ada. Basically my desire is to be able to say:
Code A may only be executed by code B but not by anybody else
Thanks for any help.
Edit:
I add a diagram here with a program structure like I have in mind that shows that what I mean here is a transport of a data structure across a wide area of the software, definition, creation and use of a record should happen in code sections that are otherwise unrleated
I think the key is to realize that, unlike C++ and other languages, Ada's primary top-level unit is the package, and visibility control (i.e. public vs. private) is on a per-package basis, not a per-type (or per-class) basis. I'm not sure I'm saying that correctly, but hopefully things will be explained below.
One of the main purposes of friend in C++ is so that you can write two (or more) closely related classes that both take part in implementing one concept. In that case, it makes sense that the code in one class would be able to have more direct access to the code in another class, since they're working together. I assume that in your C++ example, Secret and Client have that kind of close relationship. If I understand C++ correctly, they do all have to be defined in the same source file; if you say friend class Client, then the Client class has to be defined somewhere later in the same source file (and it can't be defined earlier, because at that point the methods in Secret or Secret_Interface haven't yet been declared).
In Ada, you can simply define the types in the same package.
package P is
type Secret is tagged private;
type Client is tagged private;
-- define public operations for both types
private
type Secret is tagged record ... end record;
type Client is tagged record ... end record;
-- define private operations for either or both types
end P;
Now, the body of P will contain the actual code for the public and private operations of both types. All code in the package body of P has access to those things defined in P's private part, regardless of which type they operate on. And, in fact, all code has access to the full definitions of both types. This means that a procedure that operates on a Client can call a private operation that operates on a Secret, and in fact it can read and write a Secret's record components directly. (And vice versa.) This may seem bizarre to programmers used to the class paradigm used by most other OOP languages, but it works fine in Ada. (In fact, if you don't need Secret to be accessible to anything else besides the implementation of Client, the type and its operations can be defined in the private part of P, or the package body.) This arrangement doesn't violate the principles behind OOP (encapsulation, information hiding), as long as the two types are truly two pieces of the implementation of one coherent concept.
If that isn't what you want, i.e. if Secret and Client aren't that closely related, then I would need to see a larger example to find out just what kind of use case you're trying to implement.
MORE THOUGHTS: After looking over your diagram, I think that the way you're trying to solve the problem is inferior design--an anti-pattern, if you will. When you write a "module" (whatever that means--a class or package, or in some cases two or more closely related classes or packages cooperating with each other), the module defines how other modules may use it--what public operations it provides on its objects, and what those operations do.
But the module (let's call it M1) should work the same way, according to its contract, regardless of what other module calls it, and how. M1 will get a sequence of "messages" instructing it to perform certain tasks or return certain information; M1 should not care where those messages are coming from. In particular, M1 should not be making decisions about the structure of the clients that use it. By having M1 decree that "procedure XYZ can only be called from package ABC", M1 is imposing structural requirements on the clients that use it. This, I believe, causes M1 to be too tightly coupled to the rest of the program. It is not good design.
However, it may make sense for the module that uses M1 to exercise some sort of control like that, internally. Suppose we have a "module" M2 that actually uses a number of packages as part of its implementation. The "main" package in M2 (the one that clients of M2 use to get M2 to perform its task) uses M1 to create a new object, and then passes that object to several other packages that do the work. It seems like a reasonable design goal to find a way that M2 could pass that object to some packages or subprograms without giving them the ability to, say, update the object, but pass it to other packages or subprograms that would have that ability.
There are some solutions that would protect against most accidents. For example:
package M1 is
type Secret is tagged private;
procedure Harmless_Operation (X : in out Secret);
type Secret_With_Updater is new Secret with null record;
procedure Dangerous_Operation (X : in out Secret_With_Updater);
end M1;
Now, the packages that could take a "Secret" object but should not have the ability to update it would have procedures defined with Secret'Class parameters. M2 would create a Secret_With_Updater object; since this object type is in Secret'Class, it could be passed as a parameter to procedures with Secret'Class parameters. However, those procedures would not be able to call Dangerous_Operation on their parameters; that would not compile.
A package with a Secret'Class parameter could still call the dangerous operation with a type conversion:
procedure P (X : in out Secret'Class) is
begin
-- ...
M1.Secret_With_Updater(X).Dangerous_Operation;
-- ...
end P;
The language can't prevent this, because it can't make Secret_With_Updater visible to some packages but not others (without using a child package hierarchy). But it would be harder to do this accidentally. If you really wish to go further and prevent even this (if you think there will be a programmer whose understanding of good design principles is so poor that they'd be willing to write code like this), then you could go a little further:
package M1 is
type Secret is tagged private;
procedure Harmless_Operation (X : in out Secret);
type Secret_Acc is access all Secret;
type Secret_With_Updater is tagged private;
function Get_Secret (X : Secret_With_Updater) return Secret_Acc;
-- this will be "return X.S"
procedure Dangerous_Operation (X : in out Secret_With_Updater);
private
-- ...
type Secret_With_Updater is tagged record
S : Secret_Acc;
end record;
-- ...
end M1;
Then, to create a Secret, M2 would call something that creates a Secret_With_Updater that returns a record with an access to a Secret. It would then pass X.Get_Secret to those procedures which would not be allowed to call Dangerous_Operation, but X itself to those that would be allowed. (You might also be able to declare S : aliased Secret, declare Get_Secret to return access Secret, and implement it with return X.S'access. This may avoid a potential memory leak, but it may also run into accessibility-check issues. I haven't tried this.)
Anyway, perhaps some of these ideas could help accomplish what you want to accomplish without introducing unnecessary coupling by forcing M1 to know about the structure of the application that uses it. It's hard to tell because your description of the problem, even with the diagram, is still at too abstract a level for me to see what you really want to do.
You could do this by using child packages:
package Hidden is
private
A : Integer;
B : Integer;
end Hidden;
and then
package Hidden.Client_A_View is
function Get_A return Integer;
procedure Set_A (To : Integer);
end Hidden.Client_A_View;
Then, Client_A can write
with Hidden.Client_A_View;
procedure Client_A is
Tmp : Integer;
begin
Tmp := Hidden.Client_A_View.Get_A;
Hidden.Client_A_View.Set_A (Tmp + 1);
end Client_A;
Your question is extremely unclear (and all the C++ code doesn't help explaining what you need), but if your point is that you want a type to have some publicly accessible operations, and some private operations, then it is easily done:
package Example is
type Instance is private;
procedure Public_Operation (Item : in out Instance);
private
procedure Private_Operation (Item : in out Instance);
type Instance is ... -- whatever you need it to be
end Example;
The procedure Example.Private_Operation is accessible to children of Example. If you want an operation to be purely internal, you declare it only in the package body:
package body Example is
procedure Internal_Operation (Item : in out Instance);
...
end Example;
Well I was wondering if anything of this sort is possible in Ada. Basically my desire is to be able to say:
Code A may only be executed by code B but not by anybody else
If limited to language features, no.
Programmatically, code execution can be protected if the provider must be provided an approved "key" to allow execution of its services, and only authorized clients are supplied with such keys.
Devising the nature, generation, and security of such keys is left as an exercise for the reader.
I have a variable in a package (rec in this case) that needs to be set when called from package 3, but it's private. Previously the function set_true only set rec to true, so it wasn't a big deal. But I have another package that does the same processing (I'm giving a simple example, but my literal case is more complex), so I thought, well I could pass in the variable I want modified, and let it get changed. Is the only way to set rec in the below layout, to create a second function in package one, that calls set_true with rec as the parameter? I would like to avoid having to keep creating additional functions to handle the local variables. I can't move the variable to public (spec) as I am trying to follow convention and this "type" of variable isn't public anywhere else, and I don't want anyone to be able to just set it on their own (I want functions to have to set). I don't want to have to create a second function named for example set_local_true, and creating an overloaded function set_true, with no parameters, that calls set_true(value => rec) just seems deceptive, does anyone have any better suggestions with the limitations I have?
My two requirements:
Can't make the local variable public.
Be able to use the function to calculate something both externally and internally.
package one is
procedure set_true(value : out Boolean);
end one;
package body one is
rec : Boolean;
begin
procedure set_true(value : out Boolean)
begin
value := true;
end set_true;
end one;
package body two is
local_rec : Boolean;
begin
procedure call_function is
begin
one.set_true(value => local_rec);
end call_function;
end two;
package body three is
begin
procedure call_function is
begin
one.set_true(value => <PACKAGE ONE'S REC))
end call_function;
end three;
EDIT: Or perhaps, what would be a better naming convention for the functions to specify that they are modifying the variable that is local to that package? Set_Local_True again is deceptive cause if you call it from package 3, you're not setting your local true, you're setting package one's local to true....
First off, this is very silly code. I'll assume it is shorthand for something else. But as presented, I can assure you that your clients can set their own booleans themselves without you writing a routine to do it for them. In fact, they can do it better. For the remainder of this answer, I'll assume you aren't acutally writing variables to set booleans for people, but rather doing something of actual use. If not, ignore the rest of this answer and just delete your silly routines.
Secondly, if you are creating a routine with a single out parameter, then unless the object happens to be very large, you should probably make it a function instead. That will allow your clients to use functional programming if they chose. The way you have it, the poor coder has to stop and create a special variable just to call your routine, even if they only want to do it once.
Thirdly, rather than using a unique set routine for each state, I generally prefer to pass in the requested state.
function Set_Frobnost (New_State : boolean := true) return boolean;
If the state is really and truly boolean (no possible third state in the future), then it is debateable. However, it can be a big advantage to your client if they might already have to store the state in a variable (or loop through it).
Your edit about naming shows me you are on the right track.
You should do one of two things here.
Find the higher-level concept controlled by that variable, and name the "setter" routine after that.
Get the hell out of the way and put the flag variable in the pacakge spec.
If you have to access private variables, you might to do it in a child package.
package One is
procedure Foo (X : Boolean);
private
One_Private : Boolean;
end One;
and then
package body One.Two is
procedure Bar is
One.Foo (One.One_Private);
end Bar;
end One.Two;
Elements in the "private" part of a package are like "protected" entities in C++/Java. Truly private variables (only in package body) are not accessible from anywhere else.