toJSONString and other introspections

Lars T Hansen lth at acm.org
Mon Jul 30 09:30:36 PDT 2007


On 7/30/07, Kris Zyp <kriszyp at xucia.com> wrote:

> > The agreement is that default JSON serialization will discard the
> > namespace (in the same way it currently discards eg function objects).
>
> Sounds good, howevere is there any difference in the treatment of open and
> closed namespaces in regards to inclusion of properties?

I would doubt it.  One thing that might need to be discussed is how
private/protected name spaces interact with enumeration, if at all.
In principle these properties are DontEnum, but it's possible that the
enumeration proposal allows them to be made enumerable, in which case
this becomes an issue.

> Is there any
> strategies/precedence for name conflicts that can result from multiple
> namespaces? For example:
> obj={}
> obj.b='b0';
> namespace N1;
> namespace N2;
> obj.N1::b = 'b1';
> obj.N2::b = 'b2';
> obj.N1::a = 'a';
> obj.N2::c = 'c';
> use namespace N1;
> obj.toJSONString() -> ?
> What would toJSONString return in this situation, and is it deterministic?

I'm guessing it would create a representation containing two "b"s, one
"a", and one "c".

As somebody helpfully pointed out to me, "JSON serialization" isn't
"serialization" in any reasonable sense.  It is meant for producing
JSON-compatible data.  If what you're trying to encode can't be
encoded as JSON, then tough luck -- you need a different kind of
technology.

> > That depends on the class.  The dictionary class (Map, HashMap, Dict,
> > Dictionary, Hashtable, HashTable) will probably want toJSONString to
> > capture its key-value pairs, probably, at least when those keys are
> > strings.  But it is my understanding that a user-authored class
> > deriving from Object would get Object's "toJSONString" by default, and
> > that function would perform some form of standard enumeration.
> >
>
> I was wondering about the serialization of the actual class object, not the
> class instances.

If the class has enumerable properties, then presumably enumeration
will find them and toJSONString will create some value for them.

Don't count on using toJSONString for serializing other than
JSON-compatible data.

> > At present, the meta-objects proposal (see
> >
> http://developer.mozilla.org/es4/proposals/meta_objects.html
> for an
> > older version) allows a Type object to be extracted from any value,
> > but does not specify whether those objects are the same as the
> > classes.
>
>
> I am not sure if I understand. If I write:
> class C {}
> instance = new C;
> Can I call instance.typeOf() to get C? Does the meta-object proposal allow
> me to get C from instance?

Looking at the version I have, there is a global function typeOf s.t.
typeOf(x) returns a Type object representing the manifest type of x.
The type "Type" is an interface, there are subinterfaces, like
ClassType.  "Object" is a type that implements the ClassType
interface, for example.  The way I read the proposal at present,

  class C {}
  instance = new C;
  t = intrinsic::typeOf(instance);

At this point t may or may not be the exact same object as C, I think
-- this needs to be clarified.  But it is "like" C, and it has a
"construct" method that creates new instances of C (sounds like a
potential security problem unless we're careful).

--lars



More information about the Es4-discuss mailing list