Function.prototype.toString to discover function dependencies

Mark S. Miller erights at google.com
Mon Sep 20 14:07:55 PDT 2010


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/75fb9ab5/attachment-0001.html>


More information about the es-discuss mailing list