toJSONString and other introspections

Kris Zyp kriszyp at
Mon Jul 30 09:11:25 PDT 2007

> 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? Is there any
strategies/precedence for name conflicts that can result from multiple
namespaces? For example:
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
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Es4-discuss mailing list