#3: Implement Array method overrides

[ca2longoria]

Child of: Remove handle/ob duality (#3)

---

Read methods

• [x] concat
• [x] filter
• [x] indexOf
• [x] join
• [x] keys
• [x] lastIndexOf
• [x] slice
• [x] some
• [x] toLocaleString
• [x] toString

Sort methods

• [x] reverse
• [x] sort

Add methods

• [x] push
• [x] unshift

Remove methods

• [ ] pop
• [ ] shift
• [ ] * splice

Accessor methods

• [ ] forEach
• [ ] map
• [ ] reduce
• [ ] reduceRight

* Present in more than one category

[ca2longoria]

I'm considering remvoing read methods from overriding. As it stands, they all simply call Array.prototype.*.apply(<Handle>,arguments), anyway.

Although... that would necessitate removing those properties, entirely. Otherwise, it would become too easy to mess with a Handle's internal structure.

Then, there's also the possibility of simply allowing the read methods access to the Handle objects, and include in the documentation a WARNING flag.

There are then three read possibilities:

1. apply to this.$
2. allow access to Handle objects
3. remove these methods entirely

[ca2longoria]

Leaning toward option 2, allowing Handle access. But perhaps 2 & 3 may both work. Provide an argument or option, either at the Model or Handle level, probably the Model, that indicates whether or not to make read/accessor methods available.

Say, safe, or unsafe.

[ca2longoria]

What of Handle<primary> = [...]?

Not sure if this belongs in this Issue, but it is pertinent in testing against ArrayHandle's overridden methods.