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
programming in a language above Javascript, I'm starting to change the
representation to be more like the high-level language they write in,
rather than display the Javascript "assembly language".) Those are
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.
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
