Function#toString revision: JSDoc comments?

Andy Earnshaw andyearnshaw at gmail.com
Mon Apr 18 15:40:56 UTC 2016


I imagine there's code in the wild that predates function.name, looking
something like this:

    var fooName = foo.toString().match(/^function (\w+)/)[1];

If a newer browser adds a preceding comment to the function then this code
will break.  The top voted answer to a question[1] on Stack Overflow would
break if the comment contained the string 'function '.

[1]: http://stackoverflow.com/q/2648293

On Sun, 17 Apr 2016 at 11:07 Isiah Meadows <isiahmeadows at gmail.com> wrote:

> I don't like the idea of including preceding comments in
> `Function.prototype.toString` itself on grounds it's harder to parse for
> other related reasons.
>
> As for anything including preceding comments, I'd be happy with something
> somewhat independent, as long as it's not requiring JSDoc to be parsed. Not
> that I have issues with that documentation format, but I don't think it
> should be in the spec itself.
>
> On Sat, Apr 16, 2016, 13:29 Jordan Harband <ljharb at gmail.com> wrote:
>
>> As I see it, the primary purpose of the `Function#toString` proposal is
>> to document what browsers already do, and tighten it down so they can't
>> deviate further (which some browsers already have begun to do with "class",
>> for example).
>>
>> "Preceding comments" would be a very hard thing to specify without unduly
>> blessing an arbitrary documentation pattern, especially one that isn't
>> universally considered to be a good thing.
>>
>> Reflection methods on functions are certainly a potential separate
>> proposal, if you can make a compelling argument that it's a good idea to
>> reflect on functions in this manner.
>>
>> On Sat, Apr 16, 2016 at 9:42 AM, Marius Gundersen <gundersen at gmail.com>
>> wrote:
>>
>>> Would it not be better to expose the names (and default values,
>>> destructurings, etc) of the function arguments using reflection? For
>>> example, Reflection.arguments(Math.max).then this method can return any
>>> JSDoc it is able to parse.
>>> On 16 Apr 2016 16:53, "Caitlin Potter" <caitpotter88 at gmail.com> wrote:
>>>
>>>> How would that interact with angular.js' Function.prototype.toString
>>>> parsing? Seems like doing that could break some content, even if it were
>>>> useful
>>>>
>>>> On Apr 16, 2016, at 10:48 AM, Axel Rauschmayer <rauschma at icloud.com>
>>>> wrote:
>>>>
>>>> Regarding this proposal:
>>>> https://github.com/tc39/Function-prototype-toString-revision
>>>>
>>>> Wouldn’t it make sense to include a preceding JSDoc-style comment in a
>>>> function’s (or method’s) `[[SourceText]]` value? Conceptually it is a part
>>>> of the function and it could be used to implement a REPL `help()` function.
>>>>
>>>> --
>>>> Dr. Axel Rauschmayer
>>>> axel at rauschma.de
>>>> rauschma.de
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160418/b8192be9/attachment.html>


More information about the es-discuss mailing list