Why does Array.prototype.slice.call(arguments) turn the arguments object into a real array, and what replaces that idiom in modern JavaScript?

## Generic by design When the specification defines `Array.prototype.slice`, it does not say "let A be the array". It converts `this` to an object, reads its `length` property, coerces that to a length, and then reads properties named `"0"`, `"1"`, and so on. Nothing in that algorithm requires the receiver to be an actual array. This genericity is intentional, and it is what method borrowing exploits. An **array-like** object is any object with a `length` property and integer-keyed properties. The classic example is `arguments`, the automatic object available inside a non-arrow function, which is array-like but is not an array and has none of the array methods on its prototype. ```js function old() { console.log(Array.isArray(arguments)); // false const args = Array.prototype.slice.call(arguments); console.log(Array.isArray(args)); // true return args.map(x => x * 2); } old(1, 2, 3); // [2, 4, 6] ``` `call` is doing the essential work: it invokes `slice` with `arguments` as the receiver. Without it there is no way to point the method at a non-array. Calling with no arguments makes `slice` copy from index 0 to `length`, so the result is a full, genuine array. ## The general borrowing pattern The same shape works for other generic methods and for other array-likes, including strings: ```js const likeArray = { 0: 'a', 1: 'b', length: 2 }; Array.prototype.join.call(likeArray, '-'); // 'a-b' Array.prototype.map.call('abc', c => c.toUpperCase()); // ['A', 'B', 'C'] Array.prototype.indexOf.call(likeArray, 'b'); // 1 ``` `apply` gets borrowed the same way, most famously for spreading an array into a variadic function before spread syntax existed: `Math.max.apply(null, nums)`. Borrowing is not universal. Methods that mutate need a writable receiver, so `Array.prototype.push.call(frozenLike, 'x')` fails under strict mode, and borrowing a mutating method onto an object you did not expect to change is a real source of bugs. Reading methods are the safe ones. ## What replaced it Since ES2015 there are three clearer tools, and new code should prefer them: ```js // 1. Rest parameter - args is already a real array, no conversion at all function modern(...args) { return args.map(x => x * 2); } // 2. Array.from - converts array-likes AND iterables Array.from({ 0: 'a', 1: 'b', length: 2 }); // ['a', 'b'] Array.from('abc'); // ['a', 'b', 'c'] // 3. Spread - converts iterables only [...'abc']; // ['a', 'b', 'c'] ``` The rest parameter is the best answer for the `arguments` case specifically, because it never creates the intermediate object at all, and it is the *only* option inside an arrow function, which has no `arguments` object of its own. ## The distinction that still bites `Array.from` and spread are not interchangeable: ```js const likeArray = { 0: 'a', 1: 'b', length: 2 }; Array.from(likeArray); // ['a', 'b'] [...likeArray]; // TypeError: likeArray is not iterable ``` Spread consumes an iterator, so the source must implement the iteration protocol. `Array.from` tries the iterator first and falls back to the `length`-and-indices reading. `arguments` happens to be iterable, so spread works on it, but a hand-rolled array-like or a host-provided collection may not be — and then only `Array.from` or the borrowing idiom works. `Array.from` also takes an optional mapping function as its second argument, `Array.from(src, fn)`, which avoids allocating an intermediate array — a small but real advantage over `[...src].map(fn)`. ## What to say in an interview The complete answer has three parts: array methods are specified generically over `length` plus index properties; `call` is what points such a method at a non-array receiver; and the idiom is legacy because rest parameters, `Array.from` and spread cover it more clearly. Adding the `Array.from`-versus-spread distinction shows you know *why* the old idiom has not vanished entirely.