[M3devel] Quake documentation: readonly
Peter Eiserloh
eiserlohpp at yahoo.com
Sun Jun 28 00:53:49 CEST 2009
In the quake documentation, in the SCOPE section the keyword
"readonly" is very briefly defined in the following:
To protect a name in the current scope, use
readonly dec = "digital"
If local or readonly are not used, all variables are
located in the outermost (global) scope.
Beware of side-effects!
Question 1: what would happen if a script attempts to
modify a readonly variable? Does it quitely fail, or
verbosely complain?
Question 2: if a readonly variable is declared at an
outer scope, and later an inner one attempts to
declare a new instance with that same name, does
the new name simply cover the old name, or does the
attempt to declare a conflicting local variable fail
(quitely, or verbosely).
Picking the last one above, can we clarify this to say:
To declare a name in the local scope, and prevent any
further changes to it after initialization, use "readonly".
When a readonly declaration occurs in the outmost scope,
then a readonly variable (i.e., a constant) is declared at
the global scope, an prevents any local variable with this
same name being declared locally.
For example:
readonly dec = "digital"
Alternatively, picking new local declaration succeeds:
To declare a name in the local scope, and prevent any
further changes to it after initialization, use "readonly".
When a readonly declaration occurs in the outermost scope,
then a readonly variable (i.e., a constant) is declared at
the global scope. A local declaration inside an inner
scope will override the global name while in that inner scope.
Specifically: I am looking at creating a user config file,
intending to override some settings. Something like:
---- BEGIN example user config file ----
% override debugging format from stab+ to DWARF2 format.
readonly m3back_flags = "-quiet -gdwarf2 -m64 -fPIC -mno-align-double"
include("usr/cm3/etc/AMD64_LINUX")
---- END user config file ----
+--------------------------------------------------------+
| Peter P. Eiserloh |
+--------------------------------------------------------+
More information about the M3devel
mailing list