setIn behavior contradicts documentation

Problem

Using collectable@0.22.0

It looks like C.setIn() tries to interact with values at times when I expect it to be interacting with keys.

See this webpackbin for a demo.

Take special note of map2, which is the operation that appears to throw the type error. Copy-pasted from the README:

import * as C from 'collectable';

const input = {
  foo: 'abc', <--- setIn tries to do stuff to 'abc' when it should be operating on input.foo...
  xyz: [3, [5, 6], 7, 9]
};
const map0 = C.from(input); // <{foo: 'abc', xyz: <[3, [5, 6], 7, 9]>}>
const map1 = C.updateIn(['xyz', 1, 0], n => 4, map0); // <{foo: 'abc', xyz: <[3, [4, 6], 7, 9]>}>
const map2 = C.setIn(['foo', 'bar'], x => 'baz', map1); // <{foo: <{bar: 'baz'}>, xyz: ...>

VM181 dll.js:9431 Uncaught TypeError: Cannot use 'in' operator to search for '@@is-collection' in abc
    at isCollection (VM181 dll.js:9431)
    at isIndexedCollection (VM181 dll.js:9434)
    at setDeep (VM181 dll.js:7644)
    at path.length.__WEBPACK_IMPORTED_MODULE_0__collectable_core__.IndexedCollection.updateEntry (VM181 dll.js:7647)
    at update (VM181 dll.js:9817)
    at HashMapStructure.@@update (VM181 dll.js:3664)
    at Object.updateEntry (VM181 dll.js:9425)
    at setDeep (VM181 dll.js:7647)
    at Object.setIn (VM181 dll.js:7639)
    at Object.<anonymous> (VM182 main.js:96)

Desired Outcome

• If the documentation is misleading, then the example would be corrected to demonstrate the actual setIn() behavior. This is likely, since there are many calls for documentation throughout the project.

• If the documentation reflects the intended API correctly, then this is a bug in the implementation of setIn()

[joefraley]

@axefrog cool, i’ll open a new issue about settling the second parameter API. i’d also like to add some list tests in for the number implication you described

[SimonMeskens]

Oh you want watching?

“gulp watch --pkg list”