LiveScript
LiveScript copied to clipboard
gkz
object and array slices by array should work
o = a: 123, b: 394, c: 321
you can do:
o<[a b]> # => [123, 394]
which is great, if you have keys = <[a b]>, this should work too:
o[...keys] # => [123, 394]
(note that o[...<[a b]>] does work)
same thing for array should work as well:
[1,2,3][...indexes] where indexes = [1,2]
this is apparently closed by the merge with coco by accident, i believe that's #162 for coco ;) please reopen.
Right now, o[...keys] becomes javascript: slice$.call(o[keys])
which will fail with Array.prototype.slice called on null or undefined
unless you have a key like "a,b"
(javascript forces the key to become a string for lookup in o).
A work-around:
out = [o[k] for k in keys]
If you use prelude:
map o, keys
Apparently o[...<[a b]>] works because the compiler optimizes it to
o['a', 'b'] which then becomes [o['a'], o['b']] by LiveScript before reaching JavaScript.
Arise, dead thread! I would be in favor of this change—I think it's the more intuitive interpretation of the syntax, and obviously more consistent given the behavior of o[...<[a b]>]. But it is a breaking change, and there is currently one test that contraindicates it in chaining.ls:
a = [0 1 2][[0 1], {2}]
eq '0,1' ''+a.0
eq '0,1' ''+a[...0] # would fail because 0 is not an array
eq 2 a.1.2
I'm still for it; what do others think?
The current behavior seems hardly intuitive. a[...b] compiles roughly to a[b].slice() (an equivalent of [...a[b]]), so I doubt anyone would want to use it with that intention. I may be wrong though.
There are, I must admit, valid use cases for the current behavior that don't neatly adapt to the new one. parts[\first \second ...\rest] as shorthand for [parts.first, parts.second].concat(parts.rest) is kind of nice. Still unintuitive IMO given the way splat works otherwise, but convenient if that's what you want.