Function.prototype.toString to discover function dependencies

Leo Meyerovich lmeyerov at gmail.com
Mon Sep 20 14:47:22 PDT 2010


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 <lmeyerov at gmail.com> 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, es-discuss-request at mozilla.org wrote:
> 
>> Send es-discuss mailing list submissions to
>> 	es-discuss at mozilla.org
>> 
>> 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
>> 	es-discuss-request at mozilla.org
>> 
>> You can reach the person managing the list at
>> 	es-discuss-owner at mozilla.org
>> 
>> 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" <erights at google.com>
>> Date: September 19, 2010 12:41:02 PM PDT
>> To: James Burke <jrburke at gmail.com>
>> Cc: commonjs at googlegroups.com, es-discuss at mozilla.org
>> Subject: Re: Function.prototype.toString to discover function dependencies
>> 
>> 
>> On Wed, Sep 15, 2010 at 5:24 PM, James Burke <jrburke at gmail.com> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> -- 
>>     Cheers,
>>     --MarkM
>> 
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100920/22ed4cf9/attachment-0001.html>


More information about the es-discuss mailing list