Syntax: Using obj.'some-attr' to mean obj['some-attr']

[JeanHuguesRobert]

This is a proposal for an enhancement.

obj.something is already the same as obj['something']

This is a good thing as it makes code much more readable.

That good thing could be expanded a little further. Leading to even more readable source code.

Problem:

Lots of protocols/formats use keywords whose syntax is not compatible with JavaScript's syntax for identifiers. A frequent case is where - is valid. HTLM is one of these cases.

For such key-words, obj.key-word breaks, it is recognized as (obj.key) - (word)

Solution:

To access a property whose name is not a valid identifier, use obj.'property-name'

[jashkenas]

This is a nice idea, but it introduces an alien syntax that saves a single character. Indexing into objects and arrays using brackets is a widely-respected notation from many programming languages.

Format	Languages
name[index] or name[index1, index2] etc	ALGOL 68, Pascal, C#
name[index]	C, C++, D, Java, ActionScript 3.0, JavaScript, Perl1, PHP, Python1, Ruby1, S-Lang1, Lua
$name[index]	Perl1, PHP, Windows PowerShell1
@name[index]	Perl 6
name(index)	Ada, Fortran, Visual Basic, Visual Basic .NET, RPG
name.(index)	OCaml
name.[index]	F#
name ! index	Haskell
(vector-ref name index)	Scheme
(aref name index)	Common Lisp
[name objectAtIndex:index]	Objective-C (NSArray * only)

(from wikipedia)

The reason that the brackets are necessary is because obj.key is very different than obj[key], being a literal name in the first, and a dynamic lookup in the second.

So are you suggesting we get rid of brackets, or just add your proposed syntax to the way it works currently?

[JeanHuguesRobert]

In my proposal obj.'key-word' would mean obj['key-word'] much like obj.key already means obj['key'] (which is very different from obj[key], as you mentioned)

I am not suggesting we get rid of brackets. Really. Trust my word. ;-)

I am just proposing an extension to the rule about the right term of a dot expression: a valid identifier or a string literal, versus the current rule: a valid identifier.

Note : AFAIK in a hash literal, the left side of key: values (the key) can already be a string literal, hence it's only logical to have the same possibily to access the hash using the dot syntax. Well, logic... :-)

[StanAngeloff]

If we enable this, we would also need to have obj.1: 'Hello'. There is no reason why strings will work, but numbers would fail... in that spirit, I don't think any of them should be part of Coffee. It's one character less, uncommon (don't know of any programming language that allows this syntax) and may lead to inconsistencies (e.g., numbers not allowed). Squarlies are cool.

[JeanHuguesRobert]

obj.1: 'Hello' is slightly useless I think.

That obj.1 is fairly useless does not make obj.'key-word' useless and I don't see why obj.'key-word' should so much imply that obj.1 should be valid too (symmetry aside)

The use case I adress is the one where keywords are not valid JavaScript identifiers (think about HTML keywords with - inside).

1 is not a keyword in any format/protocol that I know of, AFAIK.

Example:

somediv.style.width: "100%"

somediv.style.'max-width': "35em"

Or, as of today:

somediv.style.width: "100%"

somediv.style['max-width']: "35em"

We may be used to the latter, but I tend to think that the former is nicer looking / less verbose / easy to grasp.

[matehat]

If you want to get this going, you can always make a patch and include a thorough test suite, which will show us some example of how it'd look.

[olsonjeffery]

This doesn't add anything to the syntax, and the exactly two saved keystrokes that this proposed change would create don't really justify the disruptive nature of this syntax, in my opinion.

This just creates more surface area to cover in unit tests and documentation in exchange for a modestly-useful bit of syntactic sugar that is useful in only a few edge cases, as the issue creator notes.

But, as matehat notes, if someone wants to make a patch that enables this bit of syntax and the accompanying unit tests, then sure.. let's take a looksee.

[jashkenas]

Sounds like rough consensus. I also think that it's too far of a deviation from JS for too little a gain. Closing the ticket as a wontfix.