Discuss
  • toJSONString and other introspections

toJSONString and other introspections

# Kris Zyp (18 years ago)

I was wondering how toJSONString should handle objects with members of multiple namespaces? For example: namespace N1 obj = {}; obj.public::a=1 obj.N1::b=2 obj.toJSONString() -> ?

Would toJSONString simply not be able to serialize in such a way that the object can deserialized? The reference implementation does not seem to have toJSONString implemented yet. Doing an enumeration of obj returns gives an "a" and an empty string for keys, I assume that is not correct and that would not be the field names used by toJSONString. Also, Is there specific way that toJSONString should behave when called for a class? Will it just perform a normal enumeration (i.e. not override the default toJSONString)? Also, is there a way to determine what the class object is for a given object? In the reference implementation, the toString() will tell you name of the class, but is there a way to access to the class object (like getClass() in Java) from an instance object? Also, should there be any introspection available on a class object (beside the static members), such as the determining member attributes? Thanks, Kris

# Lars T Hansen (18 years ago)

On 6/25/07, Kris Zyp <kriszyp at xucia.com> wrote:

I was wondering how toJSONString should handle objects with members of multiple namespaces? For example: namespace N1 obj = {}; obj.public::a=1 obj.N1::b=2 obj.toJSONString() -> ? Would toJSONString simply not be able to serialize in such a way that the object can deserialized?

The agreement is that default JSON serialization will discard the namespace (in the same way it currently discards eg function objects).

The reference implementation does not seem to have toJSONString implemented yet.

Real Soon Now.

Also, Is there specific way that toJSONString should behave when called for a class? Will it just perform a normal enumeration (i.e. not override the default toJSONString)?

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.

Also, is there a way to determine what the class object is for a given object?

At present, the meta-objects proposal (see 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.

The type system is currently evolving, this proposal may change some.

In the reference implementation, the toString() will tell you name of the class, but is there a way to access to the class object (like getClass() in Java) from an instance object?

Also, should there be any introspection available on a class object (beside the static members), such as the determining member attributes?

See the same proposal.

# Kris Zyp (18 years ago)

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 to inclusion of properties? 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?

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.

At present, the meta-objects proposal (see 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? Thanks, Kris

# Lars T Hansen (18 years ago)

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 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

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).