helma.org/wiki/Modules and Scopes in Helma NG

Version 31

hannes — Thu, 14 Aug 2008 23:45:52 +0200

70	There is a newer article about the background and history\|ng/background and history of the Helma NG module system as well as a more up-to-date technical article\|ng/modules and scopes.

Version 30

hannes — Thu, 14 Aug 2008 23:45:25 +0200

67
68	=== Further Reading
69
70	There is a newer article about the ng/background and history of the Helma NG module system as well as a more up-to-date technical article\|ng/modules and scopes.

Version 29

hannes — Fri, 09 May 2008 14:53:55 +0200

5	# You don't have to use any special Javascript syntax to denote a namespace. Namespaces are invisible when you're insideEvery script is by its nature a separate scope, and defined assigned to a namespace by the file name from the outsidescript that imported it.
6	# It's hardly possible virtually impossible to produce a name collision, as each script lives in its own scope.
52	<dt><b>importModuleAsimportModule("helma.database", "db")</b></dt>

Version 28

hannes — Sat, 19 Apr 2008 01:23:01 +0200

11	Helma 2 NG implements this by using a <a href="http://www.mozilla.org/rhino/scopes.html#sharingscopes">separate top-level scope</a> for each loaded script file, using a shared top-level scope as prototype. A simplistic implementation of most of the behaviour described above in the Rhino shell may look like this:
26	Of course, Helma 2 NG also takes care of script reloading and stuff, and the shared module scope is really a per-thread scope that uses a really-shared scope for the really-shared stuff.

Version 27

hannes — Sat, 19 Apr 2008 01:15:57 +0200

The javascript import features in *Helma 2 NG* try to loosely imitate the *semantics of python's import statement|http://www.effbot.org/zone/import-confusion.htm* in order to allow applications to be written in a truly modular way. The magic of python's import statement is that a script never has to do anything special in order to avoid name clashes with other scripts, because every script lives in its one top level scope by default.

Version 26

hannes — Fri, 18 Apr 2008 23:06:02 +0200

Changed tags to helma ng

Version 25

hannes — Wed, 16 Apr 2008 00:41:22 +0200

48	<dd>Makes This makes the functions defined in helma/database.js available in the current scope as
54	<dd>Makes This makes the functions defined in helma/database.js available in the current scope as
60	<dd>Makes This makes the functions defined in helma/database.js available in the current scope as

Version 24

hannes — Wed, 16 Apr 2008 00:40:52 +0200

44	Then consider the following statements in another script file:
45

Version 23

hannes — Wed, 16 Apr 2008 00:34:02 +0200

26	Of course, Helma 2 also takes care of script reloading and stuff, and the shared module scope is really a per-thread scoe scope that uses another a really-shared scope for the really really-shared stuff.

Version 22

hannes — Wed, 16 Apr 2008 00:32:54 +0200

Note that the functions in helma/database.js do not care in which namespace they are loaded. They only see what is defined in their local file, and in the global scope shared by all modules. The scope that loaded the module is absolutely invisible to the loaded module! Also note that the getConnection() function in the last example can still access the Connection() constructor although it's not included in the importFromModule(). That's the power of closures!

Version 21

hannes — Wed, 16 Apr 2008 00:30:56 +0200

7	# Since scripts live in their own scope scope, imported scripts are only visible to the scripts that imported them.

Version 20

hannes — Wed, 16 Apr 2008 00:30:34 +0200

5	# You don't have to use any special Javascript syntax to denote a namespace. The path/name of your script file is Namespaces are invisible when you're inside, and defined by the default file name spacefrom the outside.

Version 19

hannes — Wed, 16 Apr 2008 00:28:56 +0200

The javascript import features in Helma 2 try to loosely imitate the *semantics of python's import statement|http://www.effbot.org/zone/import-confusion.htm* in order to allow applications to be written in a truly modular way. The magic of python's import statement is that a script never has to do anything special in order to avoid name clashes with other scripts, because every script lives in its one top level scope by default.

Version 18

hannes — Wed, 16 Apr 2008 00:28:41 +0200

The javascript import features in Helma 2 try to loosely imitate the *semantics of python's import statement|http://www.effbot.org/zone/import-confusion.htm* in order to allow applications to be written in a truly modular way. The magic of the python python's import is that a script never has to do anything special in order to avoid name clashes with other scripts, because every script lives in its one top level scope by default.

Version 17

hannes — Wed, 16 Apr 2008 00:27:17 +0200

51	<dt><b>importModuleAs("helma.dbdatabase", "db")</b></dt>
57	<dt><b>importFromModule("helma.dbdatabase", "getConnection", "Query")</b></dt>

Version 16

hannes — Wed, 16 Apr 2008 00:26:51 +0200

45	<dt><b>importModule("helma.dbdatabase")</b></dt>

Version 15

hannes — Wed, 16 Apr 2008 00:23:41 +0200

5	# You don't have to use any special Javascript syntax to denote a namespace. Just use the nameThe path/location name of your script filefile is the default name space.
6	# Yet It's hardly possible to produce a name collision, as each script lives in its own scope.

Version 14

hannes — Wed, 16 Apr 2008 00:21:56 +0200

1	The include() function javascript import features in Helma 2 tries try to loosely imitate the semantics of python's import statement\|http://www.effbot.org/zone/import-confusion.htm in order to allow applications to be written in a truly modular way. These are some The magic of the design goals:python is that a script never has to do anything special in order to avoid name clashes with other scripts, because every script lives in its one top level scope by default.
3	* By default, the include() function loads scripts into separate scopes matching the library's script name.To sum it up:
4	* The scope name can be overridden by passing a second argument to the include() function.
5	* Never is a library imported into the top level scope.
6	* If a library is imported into a scope that alreay is defined in the current script's code, the previous value is overwritten.
7	* Imported libraries are local to the script that imported them (which is possible because the script lives itself in its own scope).
8	* (If the same library is imported from different scripts within one application (possibly using different scope names), only one version of the library is instanciated and shared among the importing scripts.)?
9	* Imported libraries are aware of their location so they can use relative path names for local imports and references to other resources.
5	A simplistic implementation of most of # You don't have to use any special Javascript syntax to denote a namespace. Just use the behaviour described above in the Rhino shell may look like this:name/location of your script file.
6	# Yet hardly possible to produce a name collision, as each script lives in its own scope.
7	# Since scripts live in their own scope imported scripts are only visible to the scripts that imported them.
7	=== Implementation
8
9	Helma 2 implements this by using a <a href="http://www.mozilla.org/rhino/scopes.html#sharingscopes">separate top-level scope</a> for each loaded script file, using a shared top-level scope as prototype. A simplistic implementation of most of the behaviour described above in the Rhino shell may look like this:
10
21	Of course, Helma 2 also takes care of script reloading and stuff, and the shared module scope is really a per-thread scoe that uses another scope for the really shared stuff.
22
23	=== Example
24
25	Suppose there is a Javascript file called <code>helma/database.js</code> with the following content:
26
27	function getConnection(...) {
28	....
29	}
30
31	function Connection(...) {
32	...
33	}
34
35	function Query(...) {
36	...
37	}
38
39	<dl>
40	<dt><b>importModule("helma.db")</b></dt>
41	<dd>Makes the functions defined in helma/database.js available in the current scope as
42	helma.database.getConnection()
43	helma.database.Connection()
44	helma.database.Query()
45	</dd>
46	<dt><b>importModuleAs("helma.db", "db")</b></dt>
47	<dd>Makes the functions defined in helma/database.js available in the current scope as
48	db.getConnection()
49	db.Connection()
50	db.Query()
51	</dd>
52	<dt><b>importFromModule("helma.db", "getConnection", "Query")</b></dt>
53	<dd>Makes the functions defined in helma/database.js available in the current scope as
54	getConnection()
55	Query()
56	</dd>
57	</dl>
58
59	Note that the functions in helma/database.js do not care in which namespace they are loaded. They only see what is defined in their local file, and in the global scope shared by all modules. The scope that loaded the module is absolutely invisible to the loaded module!

Version 13

hannes — Tue, 15 Apr 2008 17:28:41 +0200

3	* By default, the scriptcore import mechanism include() function loads scripts into separate scopes matching the library's script name.
4	* The scope name can be overridden by passing a second argument to the import include() function.

Version 12

hannes — Tue, 15 Apr 2008 17:24:26 +0200

Set tags to helma 2

Version 11

hannes — Tue, 15 Apr 2008 17:23:20 +0200

1	ScriptCore is an experimental, next-generation script management module for the Rhino Javascript engine.The include() ScriptCore function in Helma 2 tries to loosely imitate the semantics of python's import statement\|http://www.effbot.org/zone/import-confusion.htm in order to allow applications to be written in a truly modular way. These are some of the design goals:
26	Of course, ScriptCore Helma 2 also takes care of script reloading and stuff.