Do you mean code splitting is not a valid scenario and should be considered buggy? It seems to be a common technique in the web community. For example, Google supports an explicit form of it in its own framework: http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html . I'm actually not even the one originating the question -- someone else asked me it and I realized I didn't know the answer!
Is http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf the right place to look into this question or is there a more recent proposal on 'use strict'? I also see " http://wiki.ecmascript.org/doku.php?id=proposals:strict_and_standard_modes&s=use+strict " and John Resig's informal blog post about it. Regards, - Leo On Sep 20, 2010, at 2:07 PM, Mark S. Miller wrote: > Hi Leo, you might want to look at > <http://groups.google.com/group/google-caja-discuss/browse_frm/thread/8df3d6419577c368?hl=en&tvc=1>. > As I've discussed with Ben Livshits, we gave up on the approach because it > requires a synchronous xhr. > > > On Mon, Sep 20, 2010 at 12:37 PM, Leo Meyerovich <[email protected]> wrote: > Perhaps worth considering for both this proposal and 'use strict' is the > common (and surprising to me, actually!) use case of code partitioning tools. > I suspect they might break some assumptions about how code is split into > source files etc. > > These tools, to minimize page/component load requirements (e.g., for large > sites or bandwidth limited devices), essentially do fine grained partitions > of source (generally at the function level), delaying their individual load > for a more optimal order. The one I'm most familiar with, Doloto, replaces > functions with stubs; the first invocation performs an on-demand load. I > believe GWT and many other frameworks have something here as well. > > So: would usage of 'require' and 'use strict' break these tools? Is there a > feasible evolution path for updating these tools to not break use of these > features? Perhaps these scenarios have already been considered -- if not, I > suspect they might cause problems. > > Regards, > > - Leo > > //also, for this particular proposal, I'd be a little worried about semantics > -- e.g., should a 'require' call nestled within a conditional throw an > exception? > > > > > On Sep 20, 2010, at 12:00 PM, [email protected] wrote: > >> Send es-discuss mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> https://mail.mozilla.org/listinfo/es-discuss >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of es-discuss digest..." >> Today's Topics: >> >> 1. Re: Function.prototype.toString to discover function >> dependencies (Mark S. Miller) >> >> From: "Mark S. Miller" <[email protected]> >> Date: September 19, 2010 12:41:02 PM PDT >> To: James Burke <[email protected]> >> Cc: [email protected], [email protected] >> Subject: Re: Function.prototype.toString to discover function dependencies >> >> >> On Wed, Sep 15, 2010 at 5:24 PM, James Burke <[email protected]> wrote: >> First time posting to the es-discuss list: >> >> Over on the CommonJS list, there is a thread about how to provide a >> module format that works in today's browsers. The traditional CommonJS >> module format cannot run in the browser via script tags without a >> transform, and some of us want a format that will work without >> transforms but can be easily hand-coded. >> >> Tom Robinson made the following suggestion, is this an acceptable use >> of Function.prototype.toString: >> >> require.def(function (require, exports, module) { >> var foo = require('foo'), >> bar = require('bar'); >> }); >> >> Where require.def would call .toString() on the function passed to it, >> regexp for the require() calls, then make sure to load those >> dependencies before executing the function that defines the module. >> >> So the toString() does not have to be an exact copy of the function, >> just enough that allows the require() calls to be found. >> >> Hi James, at >> <http://wiki.ecmascript.org/doku.php?id=strawman:function_to_string> I've >> been trying to state a usefully stronger but not impractically stronger >> spec. I like your usage pattern of "require" above, especially that it can >> be reliably recognized without a full lexing or parsing by regexp tricks, >> without getting misled by comments or quotes. (I try a similar but different >> pattern at >> <http://code.google.com/p/es-lab/source/browse/trunk/src/ses/initSES.js#276>. >> I like your's better.) >> >> Given source code, of course, either recognition trick works. Given only >> meaning preserving source code, which is the most I was willing to propose >> on that strawman page, these recognition tricks fail >> <http://wiki.ecmascript.org/doku.php?id=strawman:function_to_string#discussion>. >> Would we be willing to specify enough fidelity with the original source >> code that your trick would work? I don't know. Perhaps AST preserving? >> Perhaps preserving of some abstraction over equivalent ASTs? I would like to >> clean up Function.prototype.toString for ES-Harmony. Opinions? >> >> >> >> I am leaving out a bunch of other stuff about the browser-friendly >> module format (for instance there is a transform for this format to >> allow grouping more than one module in a file for optimized browser >> delivery and that form does not use .toString() and this approach >> *would not* be used on minified code), but the main question for the >> es-discuss list is: >> >> Is this an acceptable use of Function.prototype.toString? What >> problems would there be now or in the future? >> >> What I have found so far: >> >> The ECMAScript 3rd and 5th edition specs say the following: >> ------ >> 15.3.4.2 Function.prototype.toString ( ) >> >> An implementation-dependent representation of the function is >> returned. This representation has the syntax of a FunctionDeclaration. >> Note in particular that the use and placement of white space, line >> terminators, and semicolons within the representation string is >> implementation-dependent. >> >> The toString function is not generic; it throws a TypeError exception >> if its this value is not a Function object. Therefore, it cannot be >> transferred to other kinds of objects for use as a method. >> ------ >> >> In a 2008 es-discuss thread[1], Erik Arvidsson thought the >> "implementation-dependent" part allowed for low-memory devices to not >> keep a reversible implementation in memory. >> >> A test was run in a few browsers to test the approach[2]: modern >> desktop browsers (including IE 6+) give a usable toString() value, and >> there are many mobile browsers that also work well: Android, iOS, >> Windows Mobile, webOS and latest BlackBerry. So far BlackBerry 4.6 and >> some version of Opera Mobile may not, and there are some like Symbian >> and Bada that have not been tested yet. >> >> So one issue is not universal browser support, but enough of today's >> browsers both on desktop and mobile that it may make sense using it >> going forward. While the spec technically allows an implementation to >> produce something that might cause the above mentioned Function >> toString() approach to fail, it seems in practice it may be workable. >> >> I am a bit wary of the approach, but initial testing seems to indicate >> it may work, so I am looking to have an expert review done before >> proceeding with the approach. If any of you have other other >> information or concerns it would be good to know. >> >> James >> >> [1 ]Thread starts with this post: >> https://mail.mozilla.org/pipermail/es-discuss/2008-September/007632.html >> >> [2] Browser test page: >> http://requirejs.org/temp/fts.html >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> -- >> Cheers, >> --MarkM >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Cheers, > --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
