P T Withington
ptw at pobox.com
Thu Mar 12 13:54:08 PDT 2009
On 2009-03-12, at 16:31EDT, Brendan Eich wrote:
> On Mar 12, 2009, at 11:57 AM, P T Withington wrote:
>> 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.
I think we are a long way from needing serialize/deserialize arbitrary
Objects. Having JSON should suffice.
> 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.
And I agree that toString is next to useless as a debugging tool.
Which is why I wrote my own. In my experience of writing my own, I
have found that I've changed what I want the 'representation' of an
object to be, and continue to change that. (Since my output is
intended to help the human programmer, and not be eval-ed, I continue
to adjust how attributes of an object are sorted, labelled,
abbreviated, hidden/revealed, re-inspected, etc. Since my users are
representation to be more like the high-level language they write in,
some of the reasons I'm not in a rush to standardize what inspecting
an object means.
But, I would very much like to see a standard way to discover an
Object's constructor, and a way to enumerate _all_ the properties of
an object. I know there is a tension between security and
introspection. I don't know if this is something that can be handled
by the presumably already-overloaded strict mode.
More information about the Es-discuss