TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
Todd Coniam <[log in to unmask]>
Date:
Mon, 7 Dec 1998 19:02:19 EST
Content-transfer-encoding:
7bit
Content-type:
text/plain; charset=US-ASCII
Reply-To:
Parts/Attachments:
text/plain (37 lines)
In a message dated 07-Dec-1998 02:58:10 AM Central Standard Time,
[log in to unmask] writes:

<< I really don't like this solution because Foo_V is usable by others
procedures
 or functions
 in Bar package. And this is another disadvantage !

 The best solution seem to be the package Outer/Inner provided by Mark
 Lundquist. In this
 example only one function (or a set of function declared in Inner) could
access
 the "static"
 variable.

 Pascal.
  >>

While the single package STATIC does give visibility to all of the body, I
feel the understandability and readability of it surpasses the Outer/Inner
packages method.  As long as anyone who modifies the code understands that the
variables are not to be used outside their respective subprograms then
everyone should be happy.

You are absolutely correct to worry about the accessability of the STATIC
package variables.  I just feel that the maintainers of the package should be
trusted not to misuse them.  And that the understandability/readability
outweighs the risks.

Obviously, there is no perfect solution using Ada.  Perhaps we should consider
static variables in the next version?  Although I am sure it was already
discussed previously.  I just haven't heard the arguments and I'm not sure
which way I would lean.  But I have never seen a serious need for a local
static variable...

Todd Coniam

ATOM RSS1 RSS2