Hi Aaron,
Based on discussion and revision 14, I think all my concerns are resolved save
one (which I think is pretty much editorial at this point):
On Dec 19, 2011, at 2:46 PM, Ben Campbell wrote:
[…]
>
>
>>
>> -- section 3.4.1, paragraph 5: "If a "global" command is given the name of a
>> variable that has previously been defined in the immediate script with
>> "set", an error MUST be generated either when the script is uploaded or at
>> execution time."
>>
>> Does this conflict with the previous statement that it is okay for a global
>> and a private variable to have the same name?
>>
>> It doesn't conflict, because those variables live in separate namespaces.
>> The effect of the global command is to bind the two names. An error is
>> generated rather than specifying if the local overwrites the global value,
>> or the global overwrites the local value.
>
> I take this to mean you can have a global and a local variable with the same
> name, but not if they are in the same script, right? If so, then it would
> help to add that qualification to the 2nd paragraph in 3.4. As it is, it says
> implementation MUST allow a global and non-global variable to have the same
> name with no interaction, and doesn't exclude it from happening in the same
> script.
I think there's still a potential confusion here. If this was addressed in
revision 14, I missed it.
Thanks!
Ben.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
