From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,34257fd17abeba14 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wns14feed!worldnet.att.net!attbi_s21.POSTED!53ab2750!not-for-mail From: "Jeffrey R. Carter" Organization: jrcarter at acm dot org User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [SPARK] Code safety and information hiding References: <%%QFg.913090$084.629274@attbi_s22> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 12.201.97.176 X-Complaints-To: abuse@mchsi.com X-Trace: attbi_s21 1156122472 12.201.97.176 (Mon, 21 Aug 2006 01:07:52 GMT) NNTP-Posting-Date: Mon, 21 Aug 2006 01:07:52 GMT Date: Mon, 21 Aug 2006 01:07:53 GMT Xref: g2news2.google.com comp.lang.ada:6283 Date: 2006-08-21T01:07:53+00:00 List-Id: Stephen Leake wrote: > > In this case, it's anyone vaguely associated with launching rockets, > or working for NASA. It's intended as an assertion of authority, > hoping to instill fear and obediance in the audience. I guess I'm a rocket scientist, too, then. I've been involved with SW for space systems. > Good point. But "rocket scientists" are actually typically engineers. > The original term was for the people who made the first large rockets > actually fly; they were certainly engineers. Precision in language for technical subjects is a Good Thing. > In my system, as you alluded to above, the use of each global variable > is well documented; programmers are expected to follow the rules in > the documentation. It sounds as if we're in general agreement. > Of course, every time I add a new programmer to the team, they > discover new ways to (mis-)use the globals that were not covered by > the documentation :). Of course. If the global variables weren't there, they'd be stymied. > That would be essentially a globally visible getter/setter; the getter > must be globally visible, but the environment task which calls the > setter should not be. I don't see any way to enforce the rule of which > task is allowed to set the variable at run time. There would be no setter. You'd have something like package Mode_Handler is type Mode_ID is (...); function Current_Mode return Mode; end Mode_Handler; The body of Mode_Handler is responsible for maintaining the current mode; if necessary, callers to Current_Mode block until it has a value. This can be achieved by the environment task executing the initialization code for the package during elaboration, or by an initialization task in the package body. > It would be if I was writing the Ada language. We're stuck with > "Boolean". I'm glad you're not. "_Type" on the end of names is just 5 wasted characters. File_Type is about the only poorly named predefined type in the language. But let's not get into that discussion again. I've worked on systems that used the _Type convention, and it's workable. > That is not just true of variables; add 1 undocumented > function/procedure/package/task to the system, and you have a problem. Yes, but not generally an increase in coupling and decrease in cohesion. > Hmm. I guess I don't know what you mean by this. Above, you suggested > replacing Distribute mode by a getter/setter, where the setter > enforced the design rules. I assumed you meant that getter/setter > design was better than the global variable it replaces. Now you are > saying something else, but I don't know what. I trust I've clarified this. > Yes. And "the logic" can be as small as a 10 line function, or as > large as a 90k multi-cpu program; each has need of some state that is > visible to the entire subsystem. They need to be able to access the value, but not to modify it. Global variables may be modified from anywhere. > How did you set the variable in unit tests? By faking the message. > That I have not seen. Well, I guess I have to count Microsoft software > in that; some people seem happy with it. The customers of the SW designed around large numbers of undocumented global variables seemed satisfied with it. They weren't looking at or modifying the SW. In each case there were 1 or 2 people who had the whole system in their heads; that's the reason they were able to modify it. I guess I have a smaller head than they. And if those people ceased to be available, there would be big trouble. > now you have :). I still don't agree. > "large numbers" and "undocumented" are the key here, and as I pointed > out above, that description applies to other aspects of the software > as well; large numbers of small functions, or large numbers of > threads, are just as bad (possibly worse) as large numbers of global > variables. I'd be perfectly happy with an Ada-like language that didn't allow variables in package specs. For the Mine Detector game, I have 2 protected Booleans in the spec of the package that models the mine field. (They're protected because the original design had a task so that user input could be obtained while the model of the mine field did its thing.) That's not a terrible design, but with the changes needed to use GtkAda (which involved getting rid of the task), in retrospect it would be better to store the values in the user-interface package, which determines their values, and have the mine-field package ask the user-interface package for them. As you're probably aware, rules with "always" in them always have exceptions (including this rule). I have a rule that says always avoid global variables. I'll accept a small number of well documented global variables sometimes if the alternative is worse. -- Jeff Carter "Many times we're given rhymes that are quite unsingable." Monty Python and the Holy Grail 57