Java Reference
In-Depth Information
12. Most programming languages, including C, C
,andJavapass
parameters
positionally
. That is, the first value in the argument list is the
first parameter, the next value is the second parameter, and so on.
For long parameter lists this approach is tedious and error prone. It
is easy to forget the exact order in which parameters must be passed.
An alternative to positional parameters is
keyword parameters
.Each
parameter value is labeled with the name of the formal parameter it rep-
resents. The order in which parameters are passed is now unimportant.
For example, assume method M is declared with four parameters, a to
d.ThecallM(1,2,3,4), using ordinary positional form, can be rewritten
as M(d:4,a:1,c:3,b:2). The two calls have identical e
++
,C
ects; only the
notation used to match actual parameters to formal parameters di
ff
ers.
What changes would be needed in the semantic analysis of calls, as
defined in Figure 9.34, to allow keyword parameters?
ff
13. As mentioned in Section 9.1.6, C, C
, and Java allow non-null cases in
a switch statement to ”fall through” to the next case if they do not end
with a break statement. This option is occasionally useful, but far more
often leads to unexpected errors. Suggest how the semantic analysis of
switch statements (Figure 9.21) can be extended to issue a warning for
non-null cases that do not end in a break. (The very last case never needs
a break since there are no further cases to ”fall into.”)
++
14. Modern programming languages severely restrict the use of labels and
gotos. Java, for example, allows no gotos at all (though labeled breaks
and continues are allowed).
In early programming languages, rules were very di
erent. Gotos were
widely used. Moreover,
label variables
were sometimes allowed. That
is, a variable of type label could be defined. Label values could be
assigned to label variables, and gotos to label variables were allowed.
Thus, the following might appear:
ff
Label L;
...
if (option)
L = target1;
else L = target2;
...
goto L;
What changes are needed in the semantic analysis of gotos if label vari-
ables are allowed? What can happen if a label inside an active method
is allowed to ”escape” outside the method?
