Lawrie Schonfelder said:
>Why should there be any artificially imposed name
>management issue of this sort. Construct names and variable names are always
>contextually and syntactically distinguished. It has always been
>incomprehensible to me why they have been willy nilly dumped into the same
>catch all class causing additional unnecessary name management problems.
As I recall, at least some members of X3J3 and WG5 at the time were
thinking about a future extension to allow alphanumeric labels (e.g.
"GOTO process_item"), and that construct names would simply be a special
case of such. This would obviously clash with assigned GOTO if such a
feature had been pursued.
[NB: I'm not saying that this is the committee view, just that I did hear
these opinions at the time and that they seemed a plausible reason for
the existing design.]
Anyway, perhaps such thinking has been overtaken by events.
>In fact, I can see no good reason why the scope of a construct name
>should not be restricted to that of the construct in which it is defined.
Ugh. I take your point, but ...
[other than the incompatibility with the alphanumeric label extension...]
>The name could then be reused within the same program unit to name similar
>but disjoint constructs; something that you very often produce by editing
>and repeating code.
IMO this would be a half-way house that would satisfy few.
When "editing and repeating code", the construct name changes are fairly
trivial - and diagnosed by the compiler so they are easy to fix up. What
is more important is the variable name changes etc. Very easy to get
oneself into a mess there, and there would be little help from the
compiler.
If one is going to make constructs effectively into scoping units, one
might as well go whole hog and allow them to have declarations of variables
local to the construct.
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
([log in to unmask])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
