JavaScript needs a way of "including" script files into other script files, at least for the purposes of some of the heavyweight scripts that float around in the chrome folder. Example: If I'm working on EdAdvancedEdit.js and want a utility function in another file, I have to find that file, load up the corresponding XUL file, and add a <script> tag. Clumsy. I'm told that load() is available in the js shell that can be used to load scripts: load("path/to/script.js"); This should be enabled in the chrome to make scripting simpler :)

hmm. maybe brendan can add a few cents worth here.

i don't think this is really a JavaScript engine bug; if it's implemented it should be a feature of the embedding. mccabe, where should this live? parser?

This might be tricky, as I believe that chrome contexts are the same as the javascript contexts that web javascript pages see, and we don't want to expose load() there. Norris, can you confirm? Christine's right, it should be a feature of the imbedding. The only question is whether we actually have a place to *put* it in the imbedding that's different from the context that web javascript pages see.

It is up to the embedding to interpret the 'path' and know how (or if) to load the code. Is this just expected to be the equivelent of '#include' at script compile time or is it also expected to conditionally load script source as the code is running? The latter is a bigger task with more implications. This seems like a new class of things to plugin for the embedding. Also. If it *is* dynamic then it ought to hang off of some existing object rather than be a top level function. No? Nevertheless, I think that if this is a static #include then it needs to be a compiletime feature of the engine with 'plugin' support in the embedding. But if it is dynamic then it ought to be a feature of some embedding object only.

No JS preprocessors, if you please! This goes against years of ECMA and other grains. So load is a native method (of the global object, or some other object; TBD). It can be condition by an if and iterated using for, while, or do-while. Uh oh: now you need to suspend the executing script until the inner .js file has been read. That requires a thread, or the equivalent to capture the state of the JS engine and restore it later (said state being often on the machine stack as well as in interpreter data structures). This is looking hard without multi-threaded layout. The preprocessor idea looks better and better if you avoid making it "in-band": use XUL tags or processing instructions to compose your JS. Or, can we say that all load-able files are local files, and therefore fast to read? Even then, necko uses an asynchronous i/o model with worker threads doing the blocking reads. A "fast, synchronous" load method would have to do its own blocking reads, given an open descriptor for the local file. /be

Brendan, could you forward this bug to some appropriate person?

I'll trade you for that xpcdl bug. /be

Need to consider for architecture completeness, so marking M12. /be

Wait till the reporter is here to help me do it. /be

Pushing out till we have enough time to do this right. /be

Not likely till I get back from sabbatical. Anyone with inspiration, feel free to take this away from me. /be

Setting all Javacript bugs to rginda QA Contact.

Adding 'skins' keyword to selected chrome bugs. Please add any omissions. Sorry for any mistakes...

Peter, is this really blocking 29160 (and if so, how)? Hyatt doesn't think this bug should be 'skins'. /be

Mass-adding beta2 keyword to all skins bugs.

Okay, my mistake, thanks for pointing it out. removing skins & beta2 keywords.

...and removing blocks

OK, well, if we restrict loadable files to local ones, and we care only about XUL in chrome, then this bug asks for something already possible: var f = Components.classes['component://netscape/filespec'].createInstance() f = f.QueryInterface(Components.interfaces.nsIFileSpec); f.unixStyleFilePath = "extra.js"; eval(f.fileContents); Now I know we're not supposed to use nsIFileSpec any more, but I don't see any way to get data from JS out of an nsILocalFile or an nsFile. There should be a contents attribute, at least. Shaver and dougt, help me out! I'm going to mark this bug works for me (seems better than wontfix), and ask that Ben or anyone who finds a problem using the XPCOM file interfaces from JS, in conjunction with eval, to file specific new bugs on those XPCOM interfaces and/or their impls. Thanks, /be

Adding dougt so he can check out the back-story recorded here. /be

> f.unixStyleFilePath = "extra.js"; Isn't that dependent on some particular current working directory or something equally unpredictable. While it may be possible to do something like this, it is a poor substitute for a even a minimal JS library loading mechanism. Do we really want to encourage this? Adding mccabe 'cuz I've been trying to get him excited about doing work to support some sort of JS package scheme for the pre JS 2.0 engine we have.

you can get to the contents of a file via necko. Also, Pete Colins has been working on a File I/O package. You can check out: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=5695 This should give you a general idea of how to do this.