eval on non-strings
allen at wirfs-brock.com
Tue Feb 28 07:54:49 PST 2012
On Feb 28, 2012, at 3:07 AM, Brendan Eich wrote:
> Andreas Rossberg wrote:
>> On 28 February 2012 11:04, Brendan Eich<brendan at mozilla.org> wrote:
>>> Fail-soft in JS1 was an artifact of lack of try-catch combined with too much
>>> rushed Unix philosophy. In cases such as delete you could get a status
>>> result (boolean telling whether the delete failed hard if false, else either
>>> succeeded or found no "own" property if true). In other cases of course an
>>> implicit coercion was done (*sigh*).
>>> All water under the bridge but I agree we should not add more. Where do you
>>> see new fail-soft (or worse, fail-soft with ambiguity) being added?
>> Mainly destructuring, especially the implicit ToObject conversion of
>> the RHS that we have discussed a couple of months ago.
> Oh right. Another implicit conversion, indeed. We could revisit this if you feel strongly enough. It does not make me *sigh* though, because destructuring signals intent to pluck properties off of objects, and as I recall Allen suggested people will use this with a primitive RHS to get at prototype methods.
There is also a matter of maintaining internal insistency within a language. A language that consistently treats a common situation the say way everyplace it occurs is going to be easier to learn and feels more coherent than one that has contextually different behavior for the same situations. JS generally converts primitive values to wrapper objects whenever one is used in a context that requires an object. If we start throwing exceptions in new feature contexts that require an object we are making the language less internally consistent. We should want to avoid that situation.
Individual features shouldn't differ in common detail just because they were designed at different points in time or were defined by different people. These sorts of inconsistency are pretty easy to spot at the level of the code patterns used in the specification algorithms. When I see deviations of this sort in proposal that I'm incorporating into the spec. I generally just fix them.
Specifically regarding ToObject. It's use is important in minimizing the semantic differences between primitive values and Objects. In ES5 we eliminated the automatic wrapping of primitive values used as this values in method invocations. That means that in most cases 42 and (new Number(42)) can be used interchangeably. If we start leaving out ToObject calls in random places the distinction between a primitive value and a wrapped primitive values will start tripping people up.
Regarding the eval argument. It is actually the opposite situation. If it was being consistent with most of the rest of the language it would have done a ToString to its argument. But it didn't and to make it consistent now seems like a risky breaking change. It's a good example of why it is important to be consistent form the start. It's hard to correct later.
More information about the es-discuss