package body

package body

[Stribor40]

I have following....

package spec file
package body which contains one function and one procedure and one global variable

this global variable is array structure and function will save values into it...

I would like to access this global variable(with its data) from client file.

Is there anything wrong with doing g it this way and if there is better way to do this?

Re: package body

[sbelmont700]

On Tuesday, October 7, 2014 3:58:36 PM UTC-4, Stribor40 wrote:
> 
> Is there anything wrong with doing g it this way and if there is better way to do this?

The preferred way (open to interpretation) is to remove the object entirely, expose the type in the spec, have the client declare it as necessary, and pass it as an 'in out' argument to the functions.  Or, even better, wrap it up in a private type and so forth.

-sb

Re: package body

[Simon Wright]

Stribor40 <ikamzic@gmail.com> writes:

> I have following....
>
> package spec file
> package body which contains one function and one procedure and one
> global variable

I would call this variable package-local, since nothing outside the
package body can see it.

> I would like to access this global variable(with its data) from client
> file.

What is a "client file"? Is it another Ada package/subprogram?

> Is there anything wrong with doing g it this way and if there is
> better way to do this?

Unless I've misunderstood you, you *can't* do it this way. I suppose you
could put the variable in the (public part of) the package spec. You
might alternatively provide accessor operations; that way you could
control/validate accesses and only let the "clients" see the data you
want them to.

Re: package body

[Jeffrey Carter]

On 10/07/2014 12:58 PM, Stribor40 wrote:
> 
> package spec file
> package body which contains one function and one procedure and one global variable

A pkg body with variables global to subprograms in the pkg is considered a pkg
with state, and the variables represent that state. As such they are often
referred to as state variables rather than global.

> I would like to access this global variable(with its data) from client file.

You can't access anything from a file. Do you mean from code that uses the pkg
as a client? Things in pkg bodies cannot be accessed by anything outside the pkg
body.

> Is there anything wrong with doing g it this way and if there is better way to do this?

I'm not clear what "this way" refers to. You could move the variable to the pkg
spec and it could be accessed by clients there, but that would be A Very Bad
Idea. Variables in pkg specs are the root of all evil (or at least the cause of
horrible, impossible-to-understand code).

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51