Discuss
  • Hash style comments

Hash style comments

# Trans (12 years ago)

First time posting to the list, so please forgive if I am not following proper approach.

I'd like to make one proposal for future of EMCAScript. I would like to see support for # comment notation.

The reasons for this are more interesting than one might think.

First, of course, is the simple fact that # is a very common notation among programming languages. It is used by Shell scripts, Ruby, Python, even Coffeescript, and many others.

Secondly, # is preferable to // in that it is only one character instead of two, and albeit subjective (IMHO) it just seems a little bit more aesthetic.

But another reason, that few will at first consider, is the relationship between JSON and YAML. Their respective development teams made an effort to ensure JSON was a perfect subset of YAML. Now there is consideration of JSON5 (aseemk/json5). JSON5 adds support for comments, however it is Javascript style comments, where as YAML supports # style comments. This causes the superset-subset relationship to break. To help remedy this going forward, it would be very helpful if EMCAScript also supported # comments. The YAML spec could in turn add support for // style comments.

To be clear, I am not suggesting that // be deprecated. That would simply break far too much old code for no good reason! I am just seeking for # to be supported too.

Thanks for consideration, trans

# Rick Waldron (12 years ago)

On Wed, Aug 8, 2012 at 11:58 AM, Trans <transfire at gmail.com> wrote:

Hi. First time posting to the list, so please forgive if I am not following proper approach.

I'd like to make one proposal for future of EMCAScript. I would like to see support for # comment notation.

The # is already on hold for several potential syntax additions:

# Jussi Kalliokoski (12 years ago)

And even if it wasn't, it wouldn't make much sense to use the only punctuation symbol we have left for comments where we already have two syntaxes. :)

# Russell Leggett (12 years ago)

Not to keep being down on this post, but as long as YAML adds JS style comments, wouldn't JSON still be a strict subset?

# Brendan Eich (12 years ago)

Pedantry alert: someone noticed that JSON does not treat U+2028 and U+2029 (line terminators in JS) as space characters. So these can occur (unescaped) in JSON string literals, but not in JS string literals. Therefore JSON accepts sentences not legal in JS:

js> JSON.parse('{"a":"\u2028","b":2}') ({a:"\u2028", b:2}) js> eval('({"a":"\u2028","b":2})')

typein:11: SyntaxError: unterminated string literal: typein:11: ({"a":"( typein:11: ......^

Does YAML treat U+2028 and U+2029 the same as JSON does, or as JS does?

# Trans (12 years ago)

On Wed, Aug 8, 2012 at 1:03 PM, Rick Waldron <waldron.rick at gmail.com> wrote:

There are none left.

There are always symbol combinations (// is one). Things like /\, ||, <>, ~> etc. But maybe it should indicate its time to start

thinking about other ways of doing things instead of adding more "perlism". I really don'tlike the idea that Javascript is going to ue # for something else since I am do so much coding in Ruby and shell scripting.

Prototype-less data structures are nice when you want to avoid the baggage that comes with using Object objects ie. "inheriting" everything (methods, etc) via the [[Prototype]]

That sort of begs the question. Why would it be a good idea to avoid the baggage? Is there some huge speed improvement in doing so? It seems like a very bad idea to use such an object beyond anything but internal variables. You wouldn't want to use these for properties, it would be a crippled API, wouldn't it?

# Trans (12 years ago)

On Wed, Aug 8, 2012 at 1:03 PM, Rick Waldron <waldron.rick at gmail.com> wrote:

There are none left.

There are always symbol combinations (// is one). Things like /\, ||, <>, ~> etc. But maybe it should indicate its time to start

thinking about other ways of doing things instead of adding more "perlism". I really don'tlike the idea that Javascript is going to ue # for something else since I am do so much coding in Ruby and shell scripting.

Prototype-less data structures are nice when you want to avoid the baggage that comes with using Object objects ie. "inheriting" everything (methods, etc) via the [[Prototype]]

That sort of begs the question. Why would it be a good idea to avoid the baggage? Is there some huge speed improvement in doing so? It seems like a very bad idea to use such an object beyond anything but internal variables. You wouldn't want to use these for properties, it would be a crippled API, wouldn't it?

# Trans (12 years ago)

On Wed, Aug 8, 2012 at 2:07 PM, Russell Leggett <russell.leggett at gmail.com> wrote:

Not to keep being down on this post, but as long as YAML adds JS style comments, wouldn't JSON still be a strict subset?

Your right. That's a good point.

But it makes me sad. That means ugly // notation will start becoming prevalent in YAML documents. :(

Also, there is bigger picture too. How much better to see movement toward greater commonality between languages. Consider for instance that Ruby basically supports JSON as code now too.

# Trans (12 years ago)

Sorry for the double posts to those whom I've responded to (one to personal email and one to list). It drives me crazy that the reply-to address is not the list. As much as I try to remember that I have to reenter the mailing list address every time, I never seem to do so until the instant after I hit send. I would ask that the list admin fix this, but I suspect I will be told it's not a issue, but rather the proper way to do things. Reminds me of my cable box remote control. It's so advanced it no longer can turn my TV on and off. I have to literally walk over to the set just like in the old days! But hey the cable company assured me their remote controls were state of the art.

# Rick Waldron (12 years ago)

On Wed, Aug 8, 2012 at 7:16 PM, Trans <transfire at gmail.com> wrote:

On Wed, Aug 8, 2012 at 1:03 PM, Rick Waldron <waldron.rick at gmail.com> wrote:

There are none left.

There are always symbol combinations (// is one).

"//" is single line comments

Things like /\,

The parser will likely think that is a regular expression literal

||,

This is logical OR

<>, ~>

Sure, but does this conflict with your next argument?

etc. But maybe it should indicate its time to start thinking about other ways of doing things instead of adding more "perlism".

See above.

I really don'tlike the idea that Javascript is going to ue #

Sorry..?

for something else since I am do so much coding in Ruby and shell scripting.

Prototype-less data structures are nice when you want to avoid the baggage that comes with using Object objects ie. "inheriting" everything (methods, etc) via the [[Prototype]]

That sort of begs the question. Why would it be a good idea to avoid the baggage?

This is a well known pattern, there isn't much question begging here:

var o = {}; o.hasOwnProperty [Function: hasOwnProperty]

var o = Object.create(null) o.hasOwnProperty

undefined

var o = { proto: null } o.hasOwnProperty

undefined

The last two won't inherit from Object.prototype and won't have prototype chain lookups, property name conflicts etc[0][1]

Is there some huge speed improvement in doing so? It seems like a very bad idea to use such an object beyond anything but internal variables. You wouldn't want to use these for properties, it would be a crippled API, wouldn't it?

See footnote links

[0] developer.mozilla.org/en-US/docs/JavaScript/Guide/Inheritance_and_the_prototype_chain [1] www.devthought.com/2012/01/18/an-object-is-not-a-hash