eval on non-strings

Andreas Rossberg rossberg at google.com
Tue Feb 28 08:33:12 PST 2012

On 28 February 2012 16:54, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 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.

While I agree with this principle in general, the wider angle is that
it is just an instance of the Principle of Least Surprise. And that
can be a little bit more complicated. Last time round, all JS
programmers on which I tested the idea of "let [x, y] = 0" not
throwing were *very* surprised (outraged is a more accurate
description in some cases).


More information about the es-discuss mailing list