Helma Logo
main list history

Version 33 by bard on 30. May 2009, 12:37

47<dt><b>import("helma.databasehelma/database")</b></dt>
53<dt><b>var db = require("helma.databasehelma/database")</b></dt>

Version 32 by hannes on 25. January 2009, 19:48

47<dt><b>importModule(<dt><b>import("helma.database")</b></dt>
53<dt><b>importModule(<dt><b>var db = require("helma.database", "db")</b></dt>
59<dt><b>importFromModule(<dt><b>include("helma.database", "getConnection", "Query")</b></dt>

Version 31 by hannes on 14. August 2008, 23:45

70There is a newer article about the *ng/background *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 by hannes on 14. August 2008, 23:45

67
68=== Further Reading
69
70There 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 by hannes on 09. May 2008, 14:53

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>importModuleAs(<dt><b>importModule("helma.database", "db")</b></dt>

Version 28 by hannes on 19. April 2008, 01:23

11Helma 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:
26Of 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 by hannes on 19. April 2008, 01:15

1The javascript import features in Helma 2 *Helma 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 by hannes on 18. April 2008, 23:06

Version 25 by hannes on 16. April 2008, 00:41

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

Version 24 by hannes on 16. April 2008, 00:40

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

Version 23 by hannes on 16. April 2008, 00:34

26Of 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 shared really-shared stuff.

Version 22 by hannes on 16. April 2008, 00:32

64Note 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!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 by hannes on 16. April 2008, 00:30

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

Version 20 by hannes on 16. April 2008, 00:30

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 by hannes on 16. April 2008, 00:28

1The 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 by hannes on 16. April 2008, 00:28

1The 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 by hannes on 16. April 2008, 00:27

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

Version 16 by hannes on 16. April 2008, 00:26

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

Version 15 by hannes on 16. April 2008, 00:23

5# You don't have to use any special Javascript syntax to denote a namespace. Just use the name/location The path/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 by hannes on 16. April 2008, 00:21

1The 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.
5A 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
9Helma 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
21Of 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
25Suppose 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
59Note 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 by hannes on 15. April 2008, 17:28

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 by hannes on 15. April 2008, 17:24

Version 11 by hannes on 15. April 2008, 17:23

1ScriptCore is an experimental, next-generation script management module for the Rhino Javascript engine. ScriptCore The include() 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:
26Of course, ScriptCore Helma 2 also takes care of script reloading and stuff.

Version 10 by hannes on 15. April 2008, 10:48

14  this.global var __global__ = this.global __global__ || this;
19    scope.__proto__ = this;__global__;

Version 9 by hannes on 15. April 2008, 10:30

14  if (!global) this.global = this.global || this;
19    scope.__proto__ = global;this;

Version 8 by hannes on 15. April 2008, 10:26

11A simplistic (and only superficially non-broken) implementation of most of the behaviour described above in the Rhino shell may look like this:
13  // set reference to global object
14  if (!global) global = this;
15  
17    scope.__proto__ = this;global;
18    // scope is now a top level scope that inherits
19    // inherits from the current global, shared top level scope

Version 7 by hannes on 15. April 2008, 02:47

11A simplistic (and only superficially non-broken) implementation of most of the behaviour described above in Rhino may look like this:
17    // scope is now a top level scope that
18    // inherits from the current top level scope

Version 6 by hannes on 15. April 2008, 02:38

20
21Of course, ScriptCore also takes care of script reloading and stuff.

Version 5 by hannes on 15. April 2008, 02:36

1ScriptCore is an experimental, next-generation script management module for the Rhino Javascript engine. ScriptCore tries to loosely imitate the semantics *semantics of python's import statement 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:

Version 4 by hannes on 15. April 2008, 02:26

3* By default, import() the scriptcore import mechanism loads libraries scripts into a separate scope scopes matching the library's script name.

Version 3 by hannes on 15. April 2008, 02:20

11A simplistic implementation of most of the behaviour described above in Rhino may look like this:

Version 2 by hannes on 15. April 2008, 02:20

11A simplistic implementation of the behaviour described above in Rhino may look like this:
12
13  function include(script, as) {
14    var scope = new Object();
15    scope.__parent__ = null;
16    scope.__proto__ = this;
17    scope.load(script);
18    this[as] = scope;
19  }

Version 1 by hannes on 15. April 2008, 02:00

1ScriptCore is an experimental, next-generation script management module for the Rhino Javascript engine. ScriptCore tries to loosely imitate the semantics of python's import statement in order to allow applications to be written in a truly modular way. These are some of the design goals:
2
3* By default, import() loads libraries into a separate scope matching the library's script name.
4* The scope name can be overridden by passing a second argument to the import 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.