advanced object construction: obj.{ prop0: a, prop1: b } or similar

[michaelficarra]

I wanted to start a discussion about the syntax mentioned in the title and originally on es-discuss. It produces a modified clone of an object. So I'd like to hear whether people would have a use for it, how well it will play with other features, and exactly how we'd like it to compile/behave. I'd recommend at least reading the linked thread from es-discuss.

I believe the suggested syntax obj.{ a: b, c: d } is equivalent to Coco's {...obj, a: b, c: d}, which is another possible syntax we can consider. Coco's syntax actually has a few advantages over the one above:

• the ability to set defaults: {a: b, ...o, c: d, e: f}
• the ability to use other objects in place of keys: {...defaults, ...o, ...overrides}
• the curly braces on the outside as a visual signifier that a new object is being created

Though a negative of that syntax is the fact that it forces us to define merging semantics; something that's always a problem. But Coco's always-overwrite with only own-keys seems like a pretty sane choice.

[satyr]

ref. #815 #880

[7fe]

I do like the obj.{} syntax +1

[michaelficarra]

somewhat related: #1708

[michaelficarra]

note: This issue corresponds to the es-next proposal harmony:object_literals#object_extension_literal. An example of its usefulness can be seen at harmony:object_extension_literal_class_pattern

[joshuahhh]

My 2¢ -- the most natural syntax for object-extension in Coffeescript is splat-notation: [1, [2, 3]..., 4] gives [1, 2, 3, 4], so {a:1, {b:2, c:3}..., d:4} should give {a:1, b:2, c:3, d:4}! This is, incidentally, identical to Coco's inline object splats, so long as the (perfectly natural) "always-overwrite with only own-keys" semantics are chosen.

[michaelficarra]

I agree. I would love to copy Coco's object splats. Its advantages outweigh its drawbacks.

[epidemian]

My 2¢ -- the most natural syntax for object-extension in Coffeescript is splat-notation: [1, [2, 3]..., 4] gives [1, 2, 3, 4], so {a:1, {b:2, c:3}..., d:4} should give {a:1, b:2, c:3, d:4}! This is, incidentally, identical to Coco's inline object splats, so long as the (perfectly natural) "always-overwrite with only own-keys" semantics are chosen.

I seems Coco uses a different syntax for object splats ({a:1, {b:2, c:3}..., d:4} doesn't compile):

a = {b:2, c:3}
b = {a:1, ...:a, d:4}

Compiles to:

var a, b, ref$;
a = {
  b: 2,
  c: 3
};
b = (ref$ = {
  a: 1
}, import$(ref$, a), ref$.d = 4, ref$);
function import$(obj, src){
  var own = {}.hasOwnProperty;
  for (var key in src) if (own.call(src, key)) obj[key] = src[key];
  return obj;
}

I kinda like these semantics (regardless of where the splats should be). But i don't know how useful an addition it would be. One case that i'd say is pretty common: merging two objects, does not look particularly sexy with this syntax: c = {...:a, ...:b}. I personally would consider dynamic object keys (e.g. {"#{foo}-bar": baz} or {(anyExpr()): 42}) a more valuable sugar addition to Coffee's syntax for example.

[michaelficarra]

@epidemian: In the example I gave above, merging of 2 or more objects actually looks particularly sexy to me: {...defaults, ...options, ...overrides}.

[satyr]

({a:1, {b:2, c:3}..., d:4} doesn't compile)

Because Coco's splat operator is prefix (as in ES6).

b = {a:1, ...:a, d:4}

This form is added later to support splat in braceless objects, e.g.:

b = a: 1, ...:a, d: 4

[andreyvit]

+1. If I could only vote for one CS addition, it would be this one.

[danschumann]

Thank's to @jashkenas referencing me to "previous tickets discussing exactly the same thing" #3468, I read through the issue titles and found this.

Consider this example of transferring two properties from ob to otherOb

_.extend(  otherOb, _.pick(ob, 'prop1', 'prop2') )

it could be made much cleaner by coffee script, as well as not needing to create an object from pick

# It sets the two properties on the object
newOb{prop1, prop2} = ob

# in this case it creates a new object with the two properties
$.get('url', {}{prop1, prop2} = ob)

Deconstructing is allowed, but transferring and picking is just as prevalent if not more.

This is something I've always needed underscore for and have been thinking the syntax could be more readable.

the proposed 2 cases would output something like

(newOb.prop1 = ob.prop1, newOb.prop2 = ob.prop2, newOb)

$.get('url', (ref = {}, ref.prop1 = ob.prop1, ref.prop2 = ob.prop2, ref) )

[steffansluis]

So what is the status on this? I see this PR has been open for a long time, and it appears that everybody thinks it's a good idea to add something like this to CS. Is this a 'PR welcome' kind of situation, is there something in the works somewhere?

[danschumann]

It's getting to be that time...

[GeoffreyBooth]

Yes, this is a ‘PR welcome’ situation 😄