jslint icon indicating copy to clipboard operation
jslint copied to clipboard

Feature request: Spread syntax support in object literals

Open bunglegrind opened this issue 3 years ago • 4 comments

Is your feature request related to a problem? Please describe. It looks like the spread syntax in object literals is not supported in JSLint, possibly because when "how javascript works" was written wasn't still part of the ECMAScript standard.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax

example:

import parseq from "./parseq.js";

export default Object.freeze({
    ...parseq
});

Describe the solution you'd like Are there any possibilities to support spread syntax? Or there are good reasons to avoid it?

bunglegrind avatar May 20 '22 05:05 bunglegrind

kinda leaning against at moment ...

  • pro
    • do see some benefit in ergonomics
  • con
    • impacts program-correctness with subtle, order-related bugs when property-names collide
    • messes up current jslint-rule about keeping object-properties ascii-ordered
let foo = { aa: 1, bb: 2 };
let bar = {        bb: 3 };

// below feels like a bug-in-waiting
// where user needs to worry about property orderings:

console.log({ ...foo, ...bar, cc: 4 });
// { aa: 1, bb: 3, cc: 4 }
console.log({ ...bar, ...foo, cc: 4 });
// { aa: 1, bb: 2, cc: 4 }

Using similar Object.assign() would make the ordering clearer (but yea, it is less ergonomic):

let foo = { aa: 1, bb: 2 };
let bar = {        bb: 3 };

console.log(Object.assign({}, foo, bar, { cc: 4 }));
// { aa: 1, bb: 3, cc: 4 }
console.log(Object.assign({}, bar, foo, { cc: 4 }));
// { aa: 1, bb: 2, cc: 4 }

kaizhu256 avatar May 21 '22 01:05 kaizhu256

Just to add another point to your considerations: between Object.assign and the spread syntax, the former mutates the first argument, whereas the latter not.

bunglegrind avatar May 21 '22 05:05 bunglegrind

yep, hence the empty {} in Object.assign({}, ...) to avoid mutating the first object.

kaizhu256 avatar May 21 '22 14:05 kaizhu256

kinda leaning against at moment ...

  • pro

    • do see some benefit in ergonomics
  • con

    • impacts program-correctness with subtle, order-related bugs when property-names collide
    • messes up current jslint-rule about keeping object-properties ascii-ordered
let foo = { aa: 1, bb: 2 };
let bar = {        bb: 3 };

// below feels like a bug-in-waiting
// where user needs to worry about property orderings:

console.log({ ...foo, ...bar, cc: 4 });
// { aa: 1, bb: 3, cc: 4 }
console.log({ ...bar, ...foo, cc: 4 });
// { aa: 1, bb: 2, cc: 4 }

Using similar Object.assign() would make the ordering clearer (but yea, it is less ergonomic):

let foo = { aa: 1, bb: 2 };
let bar = {        bb: 3 };

console.log(Object.assign({}, foo, bar, { cc: 4 }));
// { aa: 1, bb: 3, cc: 4 }
console.log(Object.assign({}, bar, foo, { cc: 4 }));
// { aa: 1, bb: 2, cc: 4 }

What am I missing here, what's the point of these examples here?

console.log({ ...foo, ...bar, cc: 4 });
// { aa: 1, bb: 3, cc: 4 }
console.log({ ...bar, ...foo, cc: 4 });
// { aa: 1, bb: 2, cc: 4 }
console.log(Object.assign({}, foo, bar, { cc: 4 }));
// { aa: 1, bb: 3, cc: 4 }
console.log(Object.assign({}, bar, foo, { cc: 4 }));
// { aa: 1, bb: 2, cc: 4 }

Isn't this supposed to show some difference? Or am I totally on the wrong path here?

Hrxn avatar Jan 09 '23 03:01 Hrxn