[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