{foo.bar} as shorthand for {bar: foo.bar}

[TrevorBurnham]

Currently, you can write

obj = {@bar}

as shorthand for

obj = {foo: @bar}

and, in destructuring assignment / pattern matching (trying to make this issue search-friendly...),

{@bar} = obj

as shorthand for

{foo: @bar} = obj

However, {foo.bar} is a parse error in either context. There's a common use case for this: grabbing a subset of multiple objects simultaneously. For instance, in some code I was just writing, a function takes options, adds some other things, and passes some of those options on to another function in an unfortunately repetitious manner:

func repeat: options.repeat, log: options.log, width: dimensions.width, height: dimensions.height

This could be shortened nicely to

func {options.repeat, options.log, dimensions.width, dimensions.height}

The {@bar} syntax was introduced by issue 721, where StanAngeloff mentions an old ticket on this, but I couldn't find it [Edit: It was 482; see Stan's comment below.]. Probably best to start a fresh discussion anyway. Have at it.

[dvv]

Frankly, imho anything standing at hash key position should be treated as stringified hash key.

[StanAngeloff]

ref #482

There wasn't much discussion happening in there.

I agree with Jeremy in the sense that calls shouldn't be treated as DRY shorthands, but property accessors are different and they are quite useful.

[TrevorBurnham]

I certainly agree that calls should not be allowed. This is already the case with the @ syntax:

{@bar()} # Parse error on line 1: Unexpected 'CALL_START'

To take the other part of Jeremy's example, I see no problem with

{templates.ui.accounts.accountBadge}

being shorthand for

{accountBadge: templates.ui.accounts.accountBadge}

Neither is pretty, but the former is a definite improvement.

I also feel like it's an unfortunate inconsistency that {@bar} is allowed while {this.bar} is not. Pedagogically, it makes the explanation of what @ is a bit more complicated.

[eirikurn]

I agree, I have often wanted to do: clonedObj = {obj.name, obj.email}

Since it works for this using @

[jashkenas]

Yep, this is a duplicate of #482, and is untenable for the same reason. If we allow:

{templates.ui.accounts.accountBadge}

We also must allow:

{templates.ui[3].accounts().accountBadge}

... which isn't going to work well.

[satyr]

{templates.ui[3].accounts().accountBadge}

Coco made this possible.
Unfortunately the parens are required--I couldn't tame Jison well enough to allow arbitrary expressions there.

[michaelficarra]

I am also planning to make this possible with my coffee rewrite.

[satyr]

https://github.com/michaelficarra/coffee-of-my-dreams

Woot. Planning a fork, or directly into master?

[TrevorBurnham]

Jeremy, could you explain what you mean by "untenable"? Is

{templates.ui[3].accounts().accountBadge}

really worse than

{accountBadge: templates.ui[3].accounts().accountBadge}

? Obviously neither is great style, but disallowing the former also means disallowing the pleasantly readable

html = templates.ui[3].accounts()
{html.accountBadge}

[michaelficarra]

Planning a fork, or directly into master?

The compiler needs a rewrite. See #908, #1011, #1072, others. In the process, I'm going to make a few of my own little tweaks. Once it's complete, my hopes are that it will find common ground and merge with jashkenas/coffee-script.

[jashkenas]

Yes ... I mean that it's massively inconsistent. You're treating the value as both the key and value of the object literal, and you're restricting the case so that you can use any value ... as long as the final bit of it happens to be a plain property ... and that property happens to be a valid identifier string.

[jashkenas]

@michaelficarra: sounds awesome. If you feel like working on a branch in the main repo, go right ahead.

[TrevorBurnham]

Jeremy, I'm not seeing the inconsistency. Surely it's inconsistent that {@foo} works but {this.foo} doesn't? And if @/this is allowed, why not any other object?

[jashkenas]

Yes, and if anything, we should remove {@foo}. The reason why it's there is because @foo is treated like an identifier, grammar-wise.

[michaelficarra]

... as long as the final bit of it happens to be a plain property ... and that property happens to be a valid identifier string

That doesn't seem like too much to ask. I think that's intuitive. If you try anything else, you should only expect a syntax error.

sounds awesome

Glad you're supportive. Some people wouldn't see this as a step forward, but I do, and I'm glad you do too.

Surely it's inconsistent that {@foo} works but {this.foo} doesn't? And if @/this is allowed, why not any other object?

Yes. This.