hyphens for identifiers

[satyr]

gkz/LiveScript#28
jashkenas/coffeescript#2370

Allow - before an alphabetic character within identifiers just like Perl6, transforming to camelCase.

Pros

• Can satisfy and/or shut up snake_casers, preventing API style fragmentation.

Cons

• Incompatibility. x-y will no longer be a subtraction.

Thums-{up,down}s?

[vendethiel]

Makes me think about jashkenas/coffeescript#425
Like @jashkenas said :
"Unfortunately, we can't muck with literal identifiers. Since you can access the property of an object by a string index (obj["camelCase"]), or a variable (obj[name]), it's really out of the realm of possibility..."
What'd happen if we were to use a variable? The only (and ugly!) solution would be to apply a function to each time [] is used. Did I forgot legacy part using eval ?

[satyr]

What'd happen if we were to use a variable? The only (and ugly!) solution would be to apply a function to each time [] is used. Did I forgot legacy part using eval ?

Hm? I don't follow. Can you show me code example(s) that would be problematic?

[goto-bus-stop]

an-object = key-one: 1 key-two: 2
an-object.key-one is 1
an-object.'key-two' is not 2

[satyr]

an-object.'key-two' is not 2

Expected since key-two would be the same as keyTwo on as early as lexing. We have several aliases act like this already:

$ coco -se
  o = :: : 1
  console.log o.prototype, o'prototype', o::, o'::'

1 1 1 undefined

[vendethiel]

@satyr

obj:
  real-name: 'coco'

attribute = 'real-name'
obj[attribute]

obj will be {realName: 'coco'}, and that co will do obj['real-name'], so that'll fail.

[satyr]

Note that plain JS has similar quirks as well:

$ node
> o = {0x1: 2}
{ '1': 2 }
> o['0x1']
undefined

They are trivial compared to the incompatibility:

$ coco -bcs
  obj:
    real-name: 'coco'

({
  obj: real - {
    name: 'coco'
  }
});

[mcfog]

IMO, this feature sounds unnecessary and may hurt readability

#wtf
hidden-height = scroll-height - scroll-top - visible-height

vs

hiddenHeight = scrollHeight - scrollTop - visibleHeight

vs

hidden_height = scroll_height - scroll_top - visible_height

long variable name should be completed by editor so what separate words don't matter so much

[vendethiel]

After using it, I have the feeling that it's not so bad.

[goto-bus-stop]

I'm pro-this, by the way; although it's odd that (a): b might not be accessible through b[a], it would certainly be useful in many cases.

$ \#asdf .animate do
  margin-top: 1000px
  background-color: \#000

[satyr]

ups: 2, downs: 1

long variable name should be completed by editor so what separate words don't matter so much

It comes to matter when you're dealing with public API, where camel case is the de-facto standard.

[andrewrk]

I'd like to see this removed. It's confusing and pointless. Variables compile to camelCase, so why not just use camelCase? Instead when reading code, one has to have more cognitive overhead to understand this fact.

Also, as a snake_caser, I feel alienated.

[satyr]

as a snake_caser, I feel alienated

You deserve it. JavaScript has never been java_script.

[andrewrk]

That's title case!

[vendethiel]

it's so more readable with dashes than being camelCased ...

[andrewrk]

1. That is subjective.
2. It does not compensate for the 2 issues mentioned above:
   • Confusion / complication with arithmetic operators.
   • Cognitive overhead when reading code.

And here's another thing:

For some language features, if you don't like them, you can simply avoid them. For this language feature, I am forced to understand this concept, because this seemingly simple code:

c = a-b

Compiles differently than I think it should. So every line of code which has a dash, I have to keep this cognitive overhead in mind, even if I don't use dash-variables anywhere.

This feature makes the learning curve of coco steeper, harms the readability of coco, and the benefit that it gives is subjective. My subjective view of the way dash variables look is that they look harder to read than camelCase.

[andrewrk]

Also just to be clear, when I say I am a snake caser, this is what I mean.

some_variable
SOME_CONSTANT
someFunction
SomeClass

One convention to rule them all.

[satyr]

some_variable

some_non_function_variable you mean? That's an interesting variation of Hungarian notation.

[vendethiel]

I've read some science article about how is the brain reading, and apparently it's not that "subjective", the brain does the separation better.

[andrewrk]

The fact that the brain separates the words better makes it less readable. You don't want to read aVariableName as 3 words; you want to read it as one word.

[vendethiel]

It depends whether I want it to be understandable or not, I guess.

[andrewrk]

I am porting some code to coco from coffee-script, and now I have to go through the code looking for this.

[satyr]

I have to go through the code looking for this

Why? Were you using this feature even though you didn't like it?

[andrewrk]

from coffeescript to coco

Because the code might have a = b-c and I would need to insert a space around the hyphen.

[andrewrk]

It actually was pretty painless with a good regex, but it seems relevant to this thread.

[michaelficarra]

@superjoe30: Ever heard of regexps?

edit: looks like you have

[vendethiel]

Something like /([^\s]+)\-([^\s]+)/, "$1 - $2" I guess