On 12/17/2013 04:20 PM, Gregory Szorc wrote: > On 12/17/13, 3:57 PM, Jeff Walden wrote: >> Python exposes docstrings because they're not really comments -- >> they're first-class syntax in the language (overloaded syntax, but >> still part of the language definition). Go also includes them as part >> of the language, assuming I understand your description of its setup. >> Same for Rust, or at least same in that there's only one meaningful >> implementation of Rust, so it just *is*. C# and Java defined it as >> part of the language (or standard library, same thing there). >> >> Clang with C++ is the only exception to the rule that this stuff is >> defined by the language, of the examples you discuss. (Although note >> that C++11 these days -- in spec, if not in too many implementations >> -- has attributes and goes into considerable, intricate detail about >> what an attribute "appertains to".) You're talking >> implementation-proprietary feature development, pretty much, there. I >> don't have much confidence in our ability to do that as (see below) a >> language extension, to be honest. >> >>> I guess what I'm trying to say is that SpiderMonkey/JavaScript >>> appears lacking in the "language services" arena. >> >> That's entirely fair. And I think it is a language-level thing, that >> should be defined in the language proper. Just as it is in Python, >> Go, Rust, C#, Java, and in C++'s attribute syntax. (And maybe >> elsewhere, in C++1y? Wish we'd had this discussion a few months ago >> before that discussion about what we'd bring to the C++ table for >> desires in future C++ specs, to get the desires out there for >> discussion.) >> >> To the best of my knowledge, no one has proposed anything related to >> comments or documentation in ECMAScript as language functionality on >> es-discuss. (That knowledge being occasional mailing-list skimming, >> mostly of subject lines, occasionally of message bodies, plus a quick >> subject search for "comment" and for "document" just now.) If this is >> that important, we should propose something, then champion it through. >> >> But to be honest, this isn't something I think SpiderMonkey people >> should be doing. We understand language semantics. But this is far >> more an ease-of-use-ish sort of thing, that's better understood, >> described, specified, brainstormed for information/solutions/details, >> etc. by active JS authors. I'm not sure anyone on the SpiderMonkey >> team fits that bill these days. We can kibitz pretty well on this, >> but the starting point has to be people who write JS regularly, and >> have dealt with JS documentation setups before and are aware of the >> full range of what's out there, what's needed, etc. Perhaps devtools >> people who work with/in JS regularly could help out here, for >> synergistic goodness or something? > > Thanks for the info Jeff. I'm not a language designer, so lots of my > examples were probably made in ignorance of how "language design works." > That being said, as an end-user of JavaScript, I find the lack of decent > "language services" very frustrating and the first people I look at are > the providers of the JS engines, because that's who in my mind is > responsible for them (e.g. Reflect.parse()) and who I have influence > over (courtesy of being a Mozillian). For SpiderMonkey, I naturally look > at the SM engine dev team. The ECMAScript standardization process is > largely invisible to me and I trust others to spend the time and > expertise to proxy opinions like mine to that body. I assumed someone on > this list could do that. But it sounds like I'm wrong? > > I'm not sure what else I need to do. I believe I've clearly articulated > that JavaScript's language tools pale in comparison to most other widely > used programming languages and I strongly believe this is holding > JavaScript back in ways. Is the next step then to take this to es-discuss?
Yes. I'd also hop on #jslang and talk to jorendorff and dherman about your idea: try to find a champion for the feature on the spec committee who can help with the language design aspects and drive the idea forward. I, for one, love python's docstrings and have wanted to see something similar in javascript for ages. I expect my sentiment will be shared by enough people to make it happen if you iron out the specifics and find the right forum to present it. Good luck! Terrence > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
