Closed Bug 14949 Opened 25 years ago Closed 24 years ago

[FEATURE] Need to support load() in chrome contexts

Categories

(Core :: JavaScript Engine, enhancement, P3)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows 95
Type:
enhancement

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bugs, Assigned: brendan)

Details

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
Assignee: mccabe → brendan
Brendan, could you forward this bug to some appropriate person?
I'll trade you for that xpcdl bug.

/be
Status: NEW → ASSIGNED
Target Milestone: M12
Need to consider for architecture completeness, so marking M12.

/be
Target Milestone: M12 → M13
Wait till the reporter is here to help me do it.

/be
Target Milestone: M13 → M14
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
Target Milestone: M14 → M16
Setting all Javacript bugs to rginda QA Contact.
QA Contact: cbegle → rginda
Adding 'skins' keyword to selected chrome bugs.  Please add any omissions.  
Sorry for any mistakes...
Keywords: skins
Blocks: 29160
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.
Keywords: beta2
Okay, my mistake, thanks for pointing it out.  removing skins & beta2 keywords.
Keywords: beta2, skins
...and removing blocks
No longer blocks: 29160
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
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
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.
You need to log in before you can comment on or make changes to this bug.