begin clause in package bodies

begin clause in package bodies

[Mehdi Saada]

I am a beginner, and curious...
How is used the "begin" clause in package bodies, usually ? Since package are libraries, I didn't think it could also behave like a procedure (or a task, since I assume it runs in parallel with the program calling it ?).
[begin
   handled_sequence_of_statements]
end [[parent_unit_name.]identifier];

Re: begin clause in package bodies

[Anh Vo]

On Thursday, November 30, 2017 at 3:28:17 PM UTC-8, Mehdi Saada wrote:
> I am a beginner, and curious...
> How is used the "begin" clause in package bodies, usually ? Since package are libraries, I didn't think it could also behave like a procedure (or a task, since I assume it runs in parallel with the program calling it ?).
> [begin
>    handled_sequence_of_statements]
> end [[parent_unit_name.]identifier];

I call it package constructor since it is executed during package elaboration. Thus, it is used to initialize certain data such as database and so on.

Anh Vo 

Re: begin clause in package bodies

[Jeffrey R. Carter]

On 12/01/2017 12:28 AM, Mehdi Saada wrote:
> I am a beginner, and curious...
> How is used the "begin" clause in package bodies, usually ? Since package are libraries, I didn't think it could also behave like a procedure (or a task, since I assume it runs in parallel with the program calling it ?).
> [begin
>     handled_sequence_of_statements]
> end [[parent_unit_name.]identifier];

This is executed once, as the last thing during elaboration of the package, and 
provides for initialization that would not be otherwise possible.

-- 
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

Re: begin clause in package bodies

[Mehdi Saada]

Ok. But it has to be a limited practice right ?
I read using package with internal states or global variable was bad, regards to hiding implementation details, further development and concurrent programming. Less a problem Using a generic than can be instanced anywhere though.

Re: begin clause in package bodies

[Dmitry A. Kazakov]

On 01/12/2017 14:05, Mehdi Saada wrote:
> Ok. But it has to be a limited practice right ?

No. It is cleaner and safer than singletons implemented by a controlled 
object at the library scope.

> I read using package with internal states or global variable was bad,

Initialization is not a state nor a global variable. Prior to 
initialization there is no state at all, the thing stateful or not does 
not yet exist.

> Less a problem Using a generic than can be instanced anywhere though.

Generics (static polymorphism) are orthogonal to the issue of 
initialization.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: begin clause in package bodies

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> I read using package with internal states or global variable was bad,
> regards to hiding implementation details, further development and
> concurrent programming.

This seems to be very wrong advice. Do you have a reference?

Re: begin clause in package bodies

[Mehdi Saada]

No, sorry, it was some time ago. Was talking about reuse and distributed programming. I'll tell here when I'll stumble upon it again. Yet, I find it logical. Such global variables can be corrupted by one program in a unforeseen way, and corrupt another program using/reading it.

Re: begin clause in package bodies

[Dmitry A. Kazakov]

On 2017-12-01 16:15, Mehdi Saada wrote:

> Such global variables can be corrupted by one program in a 
> unforeseen way, and corrupt another program using/reading it.
No, they cannot. Package elaboration is guaranteed to happen before its 
first use. It means that any outside access will happen after the 
package initialization. Once initialization is done it is done. 
Initialization is not a "variable", global or local.

Furthermore the term "global" does not quite apply to Ada. Ada has 
nested scopes and a variable may exist in any scope starting from the 
local one up to the library level. This also applies to task objects.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: begin clause in package bodies

[Jeffrey R. Carter]

On 12/01/2017 02:05 PM, Mehdi Saada wrote:
> Ok. But it has to be a limited practice right ?
> I read using package with internal states or global variable was bad, regards to hiding implementation details, further development and concurrent programming. Less a problem Using a generic than can be instanced anywhere though.

There's nothing wrong with a package with internal state. This is the standard 
implementation of a singleton object in Ada. If the package is not task safe, 
that should be noted clearly in the package spec. It's also possible for such 
packages to be task safe.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17

Re: begin clause in package bodies

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ovrtsh$bia$1@gioia.aioe.org...
...
> Furthermore the term "global" does not quite apply to Ada.

<pedantic>Well, actually it does: "global" is defined by RM 8.1(15). 
:-)</pedantic>

>... Ada has nested scopes and a variable may exist in any scope starting 
>from the local one up to the library level. This also applies to task 
>objects.

...but your point is right. Ada defines "global" relative to the "current" 
declarative region, a rather useless definition. I prefer to think of 
"global" as equivalent to library-level, since that is always global to 
anything being executed. But I think you're right that it is better to think 
of nesting always and avoid thinking about "global" and "local" as if those 
are the only possibilities.

                                   Randy.

Re: begin clause in package bodies

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:ly8tembijz.fsf@pushface.org...
> Mehdi Saada <00120260a@gmail.com> writes:
>
>> I read using package with internal states or global variable was bad,
>> regards to hiding implementation details, further development and
>> concurrent programming.
>
> This seems to be very wrong advice. Do you have a reference?

Isn't it just confused rather than wrong? A package with an internal state 
can't safely be used concurrently unless that state is synchronized somehow, 
which is expensive. OTOH, most packages don't need to be used concurrently, 
and in that case, hiding internal states is way better than leaving the 
state open for anyone to mess with. (One problem is telling these two sorts 
of packages apart, something that hopefully Ada 2020 will help with using 
its Global aspect.)

                              Randy.