Array functions

[tomek-he-him]

• concat
• copyWithin
• entries
• every
• fill
• filter
• find
• findIndex
• forEach
• includes
• indexOf
• join
• keys
• lastIndexOf
• map
• pop
• push
• reduce
• reduceRight
• reverse
• shift
• slice
• some
• sort (immutable version)
• splice (immutable version)
• toLocaleString
• toString (does it make sense? we have the native String())
• unshift
• values

[tomek-he-him]

Refs #125 (comment)

concat, push and shift have some strange behaviours. Let’s make them more predictable:

push(3, [1, 2])      ===  // This is ready – thanks @stoeffel
shift(1, [2, 3])     ===
concat([3], [1, 2])  ===
[1, 2, 3];

concat(3, [1, 2]);  // TypeError!

[tomek-he-him]

Does pop and unshift make any sense?

head([1, 2, 3]);  //» 1
unshift([1, 2, 3]);   //» [2, 3]

[davidchase]

@tomekwi question... is there a need to do shift which seems to be a syntactic sugar for
drop(1, [1,2,3]) which seems to have a different notation here than some thing like
drop = (n, xs) => xs.slice(n, Infinity) you would get the same thing you get with native shift plus immutability thoughts?

[tomek-he-him]

Oh yeah, I seem to have mixed up shift with unshift. I meant unshift up in #107 (comment) and shift in the next message. I use the native ones very rarely anyway.

Your idea for drop seems very reasonable to me. Perhaps another name like omit would make sense?

And yeah, this whole library is really just synctatic sugar. Sugar is great when you use stuff often. So if it turns out that omit(1, …) is a useful thing, we can upgrade that to a separate function.

[davidchase]

Gotcha yeah sorry coming from ramda land so drop and omit have a different implementation and usage. But omit as you mention above would useful imho.