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
