object slice/reconstruction: pulling selected properties from an object

[michaelficarra]

I would like to propose a syntax similar to one in #1632 for creating an object from specified properties of another object. This syntax would solve the same problem that the proposal in #1617 is trying to solve (and I briefly mentioned over there).

# proposed:
a = b.{c, d, e}
# current:
a = { c: b.c, d: b.d, e: b.e }

The only downside that I can find shows itself when you need to reference a dynamic property name:

# proposed:
a = b.{ "#{c}" }
# current:
_ref = null; a = {}; a[_ref = b[c]] = _ref

It's still a lot better than the current alternative. Though, we should probably only allow those dynamic properties if we also bring back dynamic property names in object literals.

This syntax is already available in coco, so you can try it out and see example compilations by using cup. So, thanks @satyr.

[MichaelBlume]

+1

[MichaelBlume]

under this scheme would we also have

a = b.{c.{d, e}}

compile to

a = {c: {d: b.c.d, e: b.c.e}}

?

[michaelficarra]

@MichaelBlume: I don't think so. Like an object literal, only things that qualify as a PropertyName would be allowed there. It's a list of comma-separated PropertyNames.

[paulmillr]

👍

[erisdev]

Giving this the 👍 that I thought I had already given it: 👍

This is one of my favorite things from coco. As much as I disagree with his perl-over-ruby philosophy, I think @satyr has put a lot of great ideas into coco. C:

[cpryland]

+1

[michaelficarra]

I intend to implement this within the next 3 weeks.

edit: make that 5

edit again: ugh, school. I'll get to this as soon as I can.

[shesek]

+1

[connec]

I found myself wishing for this today as a way of copying certain known properties from configuration objects and such:

class Thing
  @allowed_attributes = [ 'id', 'name', 'updated_at' ]

  constructor: (attributes = {}) ->
    @attributes = attributes{@allowed_attributes...}
    # or if you want to keep it static
    @attributes = attributes{id, name, updated_at}

Is this a feature that could make it in given a suitable PR?

Edit: coco has this as 'object slice'.

[xixixao]

There is a (imo) better syntax proposal in #3225, otherwise these are duplicates, I'd move the discussion there and close this one.

[connec]

From what I can see, #3225 is slightly different and talks only about destructuring. This seems to be discussing the inverse (restructuring?) case.

a = {}
a{b, c} = d
# VS
a = d{b, c}

The analog for arrays would be splicing vs slicing (a[b..c] = d vs d = a[b..c]).

[xixixao]

@connec Exactly. But is there any point in having both? With #3225 you can do restructuring, but not the other way around (this is not the case for splicing and slicing).

[connec]

I take your point, however I'd rather have both than one or the other, as they seem more complementary than competing.

My comparison with arrays was definitely a little flawed, it's more like the difference between:

a = []
a[0..1] = d # copy only `0` and `1` from `d` into `a`

And:

a = d[0..1] # create a new array containing only `0` and `1` from `d`
            # is there a situation where the splicing approach above couldn't replace this?

[xixixao]

@connec

a[0..1] = d # copy only 0 and 1 from d into a

Is not what the syntax denotes. d is assigned to a[0...1]. This is why, in case of slicing and splicing, the two are fundamentally different.

d = 'adam'
a = [1, 2, 3, 4]
a[0..2] = d
console.log a # ['adam', 4]

[connec]

Oh, it seems I've misunderstood that syntax (and/or the splice function) for some time, sorry. Thanks for correcting me!

I guess, then, since there is no such parity between a[b..c] = d and a = d[b..c] then there is no precedent to argue for parity between a{b,c} = d and a = d{b, c}.

That said, I still like the simplicity offered by the latter, though I admittedly can't think of any situation where the former could not be used instead (with the required a = {}).

[GeoffreyBooth]

A PR for this would be welcome.