We've talked a little bit about namespaces. Here are some definitions that should help your understanding:
So why do we bother with namespaces? The single biggest reason is that it provides structure and organization when writing large programs. (Also known as "programming in the large".) For a small program (like a simple script) sophisticated namespace management is unnecessary and gets in your way. For large programs, especiall ones that are contained in numerous files and are being written by more than one person, good namespace management is a must.
One last note: most languages support namespace management to some degree or other, some do it better than others.
Loops are a source of bugs. This is because conditions you expect to be true aren't always true, and when you expect some condition to become false, it doesn't always become false.
The cure for such ills, is to put assertions in and arround your loops in strategic places. An assertion is a conditional statement which will throw an exception, halt execution of the program, or otherwise make a stink when some unexpected condition occurs. The following is a list of recommended places to put assertions among your loops.
If you have a loop that's giving you fits because the logic seems screwy, add some assertions. They will likely reveal that something isn't getting set that should be earlier on in the program or within the body of the loop.
Section 7.2 in your book, "Problem Solving: Loop Design" found on page 255 actually contains some very good pointers on writing effective loops.
Errors happen all the time in software. Sources of errors are numerous and can be caused by anything from bad user input, to timeouts, to hardware malfunctions or line noise. There are likewise numerous approaches to error handling. The following is not necessarily a complete list, but covers the biggies.
In practice, most computing environments (operating systems and programming languages) use some combination of any of the above techniques.
As listed in the descriptions, each of these approaches have their own advantages and disadvantages. Use the approach that works best for whatever situation you are in.
FOR introduced on p. 200, syntax summary on p. 200 (note the REVERSE keyword -- handy) - Very BASIC-ish and/or Pascal-ish. Note the double-dot (..) list constructor. I like this. Note that this is the iterative looping construct; this is the one you use for iterating through all the elements in an array.
WHILE syntax: p 239 - Basically like an IF stmt, except the body will be executed as long as the conditional is true, rather than just one time. Hint: Something should happen in the body to change the conditional (also known as an exit contition).
LOOP introduced on p. 245, syntax summary on p. 250 - The general-purpose looping construct in Ada, with its accompanying EXIT and EXIT WHEN sidekicks. Be sure to review the sample code for these. I personally think this is a great way to implement a general purpose looping construct. Class exercise: How might one imititate C's do-while construct in Ada?
The section in question starts on p. 224. Basically, Subtypes allow you to restrict the range of a primitive type or an enumerated set. (i.e. Natural and Positive are subsets of Integer).
Check out the IN operator on page 225 which shows you how you can quickly test if a value is a member of a set. This is known as a set operator; which can be handy. Look at Program 6.9 on pp. 225-226 which shows how the IN operator can be used as a shortcut when iterating through Subtype lists. Very nice. It means you can use an IF instead of a FOR ... IF construct.
See the jist of the "overloading principle" on page 233. The long and the short of it is that it works just like function overloading in C++. Those example functions it lists should be part of the same package. We're not going to spend a lot of time on this.
Introduced on p. 239, more detail on p. 267, syntax summary on p. 268. It lists a few types of built-in exceptions. The example program starting at the bottom of p. 239 shows a simple example of exception handling.
Note that exceptions need to be put in a "naked" inner block (i.e. a BEGIN-END encloser). Note also that in order to handle exceptions within an iterative construct, or until correct input is recieved, you will need an enveloping outer looping blook. See the accompanying sample program beginning at the bottom of page 270, and going through page 271. It illustrates how robust input handling is accomplished.
Read the intro to Section 7.5 on page 276, including the section entitled "Writing Procedures" which extends to the next page. In a nutshell, this demonstrates how arguments passed to functions can be declared read-only, write-only, or read-write.
What you should take away from this study is the following: You can protect variables against modification within a procedure, and you can essentially return values (even multiple values) from a procedure based on access specifiers of the parameter list.
A syntax summary of how to declare / implement / call procedures is found on pp. 283-285.
Modify your assignment number three to be able to gracefully handle bad data that the user might input. When a non-floating-point number or negative floating-point number is entered, print an error message, and prompt them again for input. Do not re-save this as assn3.adb, instead, save the modified program as assn4.adb. This should only be one file.
This assignment is due the night of the first midterm, September 26th.