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?
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
