Coercing 'this' (was: Topic list - pending changes and issues for the ES3.1 spec)

Mark S. Miller erights at google.com
Wed Sep 10 10:36:47 PDT 2008


On Wed, Sep 10, 2008 at 3:07 AM, Sam Ruby <rubys at intertwingly.net> wrote:
> Let's posit for the sake of discussion that a primitive decimal type
> is in and we proceed as you describe above.  Furthermore, and just for
> the sake of simplicity as it isn't really pivotal, let's assume that
> all named Decimal methods are "static", so there is no instance
> methods of interest.
>
> In such a scenario, is there value in providing a Decimal wrapper type
> at all?  Could new Decimal('5') simply throw an exception and a
> footnote be placed someplace in the spec that ECMA TC39 reserves the
> right to change this behavior in future revs of the spec?
>
> I'm not asking because I consider a Decimal wrapper is hard to
> implement, but because I don't understand what value such a wrapper
> would provide other than to be available for the situation you
> describe above.

Symmetry. ES3 has certain regularities. As unpleasant as its choice of
symmetries are -- there should never have been separate primitives and
wrappers -- we don't get to remove them. Generic value-handling code
benefits by assuming these symmetries. Currently, for all primitive
values v,

typeof v !== 'object'
typeof Object(v) === 'object'
Object(v) !== Object(v)
Object(v).valueOf() === v

Let's not break these.


>> If primitive 'this' values are no longer coerced, we can still explain
>> the semantics of property lookup of an expression like 'foo.capture()'
>> by saying that the property is looked up in the wrapper's prototype.
>> Or we could say that the property is looked up after wrapping, but a
>> method call proceeds with the original unwrapped value. In other words
>>
>>    "foo".capture()
>>
>> should be equivalent to
>>
>>    Object("foo").capture.call("foo")
>>
>> given the original bindings for Object and Function.call.
>
> It occurs to me that the latter case (looking up after wrapping)
> trades a single wrapping at function entry against potentially
> multiple wrappings that may occur inside the function.

If we adopt the no-this-coercion rule and use wrapping only to explain
the lookup, then the implied allocation above is unobservable and can
easily be optimized away. By contrast, the allocation implied by the
current spec can only sometimes be optimized away, and only by doing
an escape analysis.

-- 
    Cheers,
    --MarkM


More information about the Es-discuss mailing list