Object.prototype.inspect ?

Brendan Eich brendan at mozilla.com
Thu Mar 12 22:04:13 PDT 2009

On Mar 12, 2009, at 8:28 PM, P T Withington wrote:

> On 2009-03-12, at 21:38EDT, Brendan Eich wrote:
>> That's the rationale in a nutshell for the de minimus ES1 (pre-ES1,  
>> I had it in Netscape 3 if not 2) setting of f.prototype.constructor  
>> to f when creating f.prototype on demand.
>> It could be argued it's too implemnetation-oriented but we had a  
>> hard time figuring out how to elaborate it without imposing a per- 
>> instance cost (as Tucker chose to do, but that was his choice) on  
>> all objects. I remember talking through this in ES1 days, early  
>> 1997 probably.
> Ideally, I could have what I want with a per-constructor cost,  
> rather than a per-instance cost.  Since we know each instance  
> already has a [[Class]] and a [[Prototype]] property and we don't  
> want to add another slot of overhead, we could expand one of those.

As an aside, you might think we could (ignoring tricks to make  
[[Class]] implicit by allocating all objects of the same class from a  
given page or larger aligned chunk of memory) eliminate [[Class]] and  
have only [[Prototype]], with internal methods such as [[Get]] and  
[[ThrowingPut]] defined so as to be unnameable by script on the  
prototype object.

This would have nice properties for composing, e.g., custom extensions  
to native instances, e.g., Date instances. Date methods such as  
Date.prototype.toString would find the internal state, named  
[[Private]], say, by looking up an unnameable-by-script identifier  
starting from the FancyDate instance, then looking in its true Date  

js> function FancyDate() {}
js> FancyDate.prototype = new Date(0)
Wed Dec 31 1969 16:00:00 GMT-0800 (PST)

Alas it doesn't work:

js> fd = new FancyDate
Date.prototype.toString called on incompatible Object

 From ES3 15.9.5:

''In following descriptions of functions that are properties of the  
Date prototype object, the phrase “this Date object” refers to the  
object that is the this value for the invocation of the function. None  
of these functions are generic; a TypeError exception is thrown if the  
this value is not an object for which the value of the internal  
[[Class]] property is "Date".''

Behold nominal typing in the built-ins, separate from prototype-based  
delegation. I regret this impurity, but it's deep and it reflects  
implementation biases of the time, still present today.

> The [[Prototype]] property is already per-constructor, but it's an  
> Object itself, and its semantics mean I can't do what I want there.   
> Along your line of thought that the [[Class]] value is not really a  
> string (because you can only get to the specified string with the  
> toString 'accessor') why can't the [[Class]] value be per- 
> constructor, and have a slot that takes you back to the constructor,  
> via some suitably-named accessor?  (Too bad `constructor` is already  
> used.)
> Perhaps this all becomes moot when I have real classes in es4, but  
> until that time...

ES4 is no more, its sound parts survive in Harmony. The "classes as  
sugar" idea lives in Harmony too, and such classes should be able to  
model or even implement the built-in nominal types, I think.

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.


More information about the Es-discuss mailing list