Object.prototype.inspect ?

Brendan Eich brendan at mozilla.com
Fri Mar 13 15:29:58 PDT 2009

On Mar 13, 2009, at 3:04 PM, Mark S. Miller wrote:

> I don't understand what is being proposed. In ES3.1 terms, what would
> Object.getConstructor do?  [[Class]].[[Constructor]].name makes no
> sense, since the value of [[Class]] is a string.

Yes, that sketch was based on an evolved notion of [[Class]],  
hypothetical of course.

There is little point in an Object.getConstructorName that is merely a  
sweeter and higher-integrity form of  
Object.prototype.toString.call(obj).slice(8, -1). Tucker argued for a  
way to get the true constructor object from a given instance. With the  
'name' property of named functions proposal recently discussed, it's  
then trivial to get the original constructor name, for both native and  
user-defined functions.

Tobie showed user-defined constructor functions Parent and Child,  
arranged with prototype-based inheritance as the names imply. One goal  
not met by anything in ES3.1 is to get the name "Parent" or "Child",  
as appropriate, given an instance or Parent or Child. Meeting that  
goal requires something other than [[Class]] as spec'ed. It also needs  
something less configurable and shadowable than the existing  
'constructor' property of the constructor function's 'prototype' object.

Thus the idea of a [[Constructor]] internal property was skirted, but  
we do not want to specify another mandatory internal property for all  
objects (even if it could be optimized away as an induction variable;  
the spec should avoid such redundant internal properties).

Wherefore the idea of [[Class]].[[Constructor]] based on making  
[[Class]] something other than string-valued.

An obvious extension is to make [[Class]] a String instance, with an  
ad-hoc non-configurable 'constructor' property, and everywhere the  
spec compares [[Class]] to a string such as "Object", use ToString  
or .toString (or even == -- impure! ;-) to get the right comparison  

This is all just a thought experiment, and actually doing the work to  
spec Object.getConstructor in ES3.1 terms, so that it satisfies the  
goal of returning a reference to the native or user-defined  
constructor that was invoked to construct obj, might lead to a better  

In any event, this issue is separate from the 'name' property of  
function instances, which Allen is deferring from ES3.1, but we're  
continuing to hash out for Harmony.

So if, as appears likely, we don't do either 'name' or  
'Object.getConstructor' for ES3.1, we may find a better Harmony- 
targeted spec formalism and particular solutions couched in it. But I  
suspect it's worth working out the minimal solution now in ES3.1 terms.

Does this help?


> On Fri, Mar 13, 2009 at 2:21 PM, Brendan Eich <brendan at mozilla.com>  
> wrote:
>> On Mar 13, 2009, at 6:22 AM, P T Withington wrote:
>>> On 2009-03-13, at 01:04EDT, Brendan Eich wrote:
>>>> To your point, which I addressed in different terms: we could make
>>>> Object.prototype.toString look for [[Class]].[[Constructor]].name  
>>>> where
>>>> [[Constructor]] is unnameable-by-script and references the class's
>>>> constructor function. This would satisfy Tobie's wish while  
>>>> avoiding the
>>>> mutation hazards inherent in using constructor.name. Either  
>>>> solution wants
>>>> the function name property to be standard.
>>> Can we go one step further?  I want (something like)
>>> Object.getOwnConstructor() to return Object.[[Class]]. 
>>> [[Constructor]].  I
>>> want to be able to get a handle on the constructor of the object,  
>>> not just
>>> the name of that constructor (since in some cases that name might be
>>> 'anonymous' which doesn't help me).  Is that a possibility?
>> For Harmony, sure. It would be Object.getConstructor, I think,  
>> since there
>> is no connotation of "get property from this object or an object on  
>> its
>> prototype chain", but Allen may have a different thought.
>> For ES3.1 the time to propose this was last year when the spec was  
>> in flux,
>> freely available for review, and not being frozen for implementation.
>> Sure, we could "sneak" Object.getConstructor in, but that is a good  
>> way to
>> be late and bloated if done for N such "easy additions", N growing  
>> quite
>> large as we go. Maybe we can agree to hold the line "just this  
>> once". I'm
>> skeptical; a precedent often takes on a life of its own.
>> /be
>> _______________________________________________
>> Es-discuss mailing list
>> Es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> -- 
>    Cheers,
>    --MarkM

More information about the Es-discuss mailing list