Object.prototype.inspect ?

Brendan Eich brendan at mozilla.com
Thu Mar 12 13:31:29 PDT 2009


On Mar 12, 2009, at 11:57 AM, P T Withington wrote:

> On 2009-03-12, at 14:28EDT, Jason Orendorff wrote:
>
>> On Wed, Mar 11, 2009 at 6:20 AM, Tobie Langel  
>> <tobie.langel at gmail.com> wrote:
>>> It is very useful to be able to specify the debugging  
>>> representation of an
>>> object distinctively from it's toJSON or toString representation.
>>
>> No doubt.  I've implemented similar functionality on every serious
>> JavaScript project I've done.
>
> Same here, but I bet I did it differently.  Which makes me think  
> this is _not_ an area for standardization.  As long as there is a  
> standard way to enumerate the properties of an Object and a standard  
> way to determine an Object's 'class' (i.e., constructor, which you  
> can only do in ES3 if you annotate each object yourself), you can  
> write your own inspect and this is a dandy place to allow  
> innovation, IMO.

This was Rok's argument against standardizing toSource/uneval in ES3  
timeframe, and it's a good one if the intention is to serialize and  
deserialize all cases preserving private state, non-enumerable  
properties, etc.

On the other hand, if the intention is to provide an easily inspected  
string representation that gives obvious or overt property values, e.g.,
uneval([0,1,[2,3]]) => "[0, 1, [2, 3]]" instead of the muddled  
toString result "0,1,2,3", then there's benefit in a common standard.


> toSource or repr can learn from Lisp, but if you really want to do  
> it right, we have along way to go.  There is a big difference  
> between being able to inspect/debug an object for human legibility  
> and expecting that you can convert an object to a source expression  
> that when evaluated will be "equal" to the original object (for some  
> definition of equal!).

Indeed. I borrowed sharp variables to handle cycles and join points in  
object graphs from Common Lisp. But I did not follow through on native  
or host object "private data", or non-enumerable properties. If object  
initialisers could express such things portably, perhaps it would be  
worth doing.

For non-deletable and non-writable properties, ES4 had at one point

obj = {var foo: "hi", const bar: 42};

It's a bit obscure that var means non-deletable. Probably brute force  
syntax is better, but I'm not going to make some up right now. It will  
be verbose, keyword-y. I'd argue the keywords (plural) need to go near  
the :, not before the identifer, and in some kind of brackets (if more  
than one, or always).

For native functions one does not want to give away code addresses,  
however. You could imagine using a crypto-hash to uniquely identify  
natives. Then one could round-trip references to native functions made  
from object properties.

/be



More information about the Es-discuss mailing list