An array destructing specification choice

John J Barton johnjbarton at johnjbarton.com
Sun Nov 6 09:50:43 PST 2011


On Sun, Nov 6, 2011 at 9:09 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>
> On Nov 6, 2011, at 8:03 AM, John J Barton wrote:
>
>> On Sat, Nov 5, 2011 at 11:16 AM, Allen Wirfs-Brock
>> <allen at wirfs-brock.com> wrote:
>>>
>>>
>>> What do you think this returns:
>>>     Array.prototype.pop.call({0:0, 1:1, length: 2, 2:2})
>>
>> The answer depends upon the definition of pop(). For an array argument
>> we can predict based on our experience with pop(). Otherwise we cannot
>> predict without more information. That's the nature of dynamically
>> typed language.
>
>
> The definition of Array.prototype.pop is precisely provided by section 15.4.4.6 of the the ECMAScript specification.  That definition applies whether or not the "this value" of the function is a "real" array or just an ordinary object.

Yes sure, I do understand that it has a precise and generic
definition. But the question you posed as "what do you think", and I
responded as a JS dev: I don't know without reading 15.4.4.6.  I
expect I have to know the details because pop(), like real JS methods,
applies to all arguments not just Arrays.

>
>>
>> Consequently this example does not bear upon the thread in my opinion.
>> In the example
>>  let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
>> the language is inserting some operation to map the RHS to the LHS.
>> The answer depends upon the operation inserted; it need not be related
>> to pop().
>
> The relevance is that pop is an example of how the ES specification consistently defines apparent array operations and functions in a manner that applies to all objects, not just instances of the Array constructor.

I'd say this somewhat differently: the built-in Array operations could
be defined to work only on Array objects, doing run-time type testing.
But, staying in the spirit of ES generally, they are not. They just do
their work and let the cards land where they fall.

>
> You said
>
>>> But the feature does not do this. Rather, since LHS is array, it
>>> coerces the RHS to an array:
>>>  let z = coerceToArray(_rhs)[0];
>>> and we don't know what that operation means.
>>
>
>
> I an showing, via pop, that we do know what it means to treat a regular object as an array.

Yes, I understood your goal, but I don't agree that you know what it
means to treat a regular object as an array.  Rather you know how to
implement pop() so it works on some non-Array objects. That knowledge
may or may not help you define other operations. Knowing that pop() is
generic and works on some non-Array objects does not, however, give me
-- the JS dev -- any hints on other methods.

If ES defined a coerceToArray, then we would know what it means to
treat an regular object as an array.

>
> Also, There is no actual "coerceToArray" operation in the ES specification and such a coercion would not occur for destructuring.  Instead, very operation/function that might access/operate upon an "array" is defined in such a way that it result is well defined for any object.

I think you are agreeing with me ;-).  You are saying there is no
common operation 'coerceToArray'. Coerce makes sense in a system of
types: to apply an Array op to any object, first coerceToArray then
apply the Array op. We don't do that in JS.

Instead each operation applies some sub-operations to the argument. If
the sub-operations succeed and make sense, then the operation succeeds
and makes sense.

Thus the answer from pop() does not tell us anything about
destructuring. We need to know the sub-operations of destructuring.

Now it is possible that *you* know an implicit coerceToArray and *you*
know it will tell us how to implement pop() and destructuring. But it
would news to me, and I guess most other devs.

>
> The ES spec. must define what happens in all cases.  That is exactly the exercise we are engaged in here.  How do we specify destructuring so that its behavior is both well defined in all situations and consistent with both other related ports of the language and with reasonable user expectations.

Yes, I total understand the challenge you face. My initial user
expectation was that destructuring was a kind of assignment. It's a
shorthand for individual assignments. So mapping the object property
at name '2' is the answer I expect.

jjb


More information about the es-discuss mailing list