Modules, Globals, System object
Just a brief note to help clarify these concepts in R3.0 and how they are related:
| | Modules | let you create an environment (context) for your script or component (extension/plugin of REBOL). A module separates your script variables from system variables as well as from other component variables (just like you may be doing today using large one-of-a-kind objects). This helps prevent accidental redefinition of system functions, objects, and other values. For example, if you wrote system: none, you're script is not going to crash. You will only be affecting your module's definition of system.
|
| | Globals | are really just the "free variables" of your script module. They are no longer global to the system or to any other module. These variables are "collected" into your module context when your module code gets bound. Additional actions such as do %file may bind additional variables to your module. As far as your script is concerned, these are globals. But, in reality, they are only global to your current module.
|
| | System | is a predefined object for accessing information about the system. The subobjects of system actually belong to different modules, and this is a problem for security. So, system is likely to change in some important ways (see prior article)... but there will still be methods for achieving the same results your script may require (such as localizing the error messages or month names, and a lot more.)
|
Note that some of the R2.0 system environment "tricks" may be quite different. For instance, the system/words object no longer exists (because there are no globals, only modules). You can get a similar list for your module, or you can gather the separate words from all installed modules and build your own list. (Although, a script requires special secure attributes to do that.)
6 Comments
|
