On Sun, Nov 6, 2011 at 9:09 AM, Allen Wirfs-Brock <[email protected]> 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
>> <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
