425514 - Treehydra: New include() function

Status: RESOLVED FIXED

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[David Mandelin [:dmandelin]]

I'm building up a fair amount of code for different purposes to work with Treehydra, and it would be convenient to have it in several files. Also, there would be enough interfile dependences that managing things with 'include' seems a little hairy. I don't know what's best, but stealing the classic ideas on this:

- idempotent include -- just includes the file once, if included again (say from a different file), nothing happens. This saves load time and prevents initialization code from running twice, which could be erroneous.

- import as module -- a separate command (or second argument to include) that causes the module to be imported into a separate namespace. This is maybe not such a great idea. Perhaps it is more JS-y (not to mention .NET-y) to namespace things within the original file?

Comment 1

[(dormant account)]

idempotent include sounds good to me. This could be combined with manual namespacing. Perhaps brendan, shaver or other javascript demigods have suggestions on this.

Comment 2

[Benjamin Smedberg]

I think we should copy the API used in mozilla for Components.utils.import:
http://developer.mozilla.org/en/docs/Components.utils.import

Files are only loaded once, and then shared. You can either load symbols into an object to use as the global:

var mymodule = {};
import("filename.js", mymodule);

or into the current global object:

import("filename.js")

This latter syntax requires that the loaded script set EXPORTED_SYMBOLS (pretty much the same thing as __all__ in python), see http://developer.mozilla.org/en/docs/Using_JavaScript_code_modules

Comment 3

[(dormant account)]

I like the moz api suggestion

Comment 4

[(dormant account)]

Attachment: Shiny include("file",[obj])

Here is my proposed include.
For every namespace, it keeps a hidden _includeArray[] to keep track of files that shouldn't be reincluded.
I now load all of the code through include(), so it'll be impossible for a script to recursively include itself(without silly tricks with pathnames).

test.js is my initial minitestcase. If anyone has objections to this speak now, or forever hold your peace.

I didn't implement this like the Component method because I dislike explicitly listing stuff for export, especially as strings.

Comment 5

[David Mandelin [:dmandelin]]

(In reply to comment #4)
> Created an attachment (id=312413) [details]
> Shiny include("file",[obj])

Looks pretty nice. Except I don't approve of the mucking around with this->globalObj, I think it would be much better to add an extra 'JS this' arg to dehydra_loadScript.

I can see arguments on either side of the listing items for export issue, but I agree with your approach.

Comment 6

[(dormant account)]

globalObj IS this :)

Comment 7

[(dormant account)]

pushed