I'd just stick with JSON. I think the reason why JSON is so popular is that it works with most languages. This would only be compatible with object oriented languages. Adding in code blocks would only make it easily compatible with one.
> This would only be compatible with object oriented languages.
Why do you think that?
It's compatible with any language with named record types, which is likely to be about any language which can parse JSON in the first place. It's particularly compatible with Erlang, which has named record types and (the equivalent of) symbols, and Erlang isn't generally considered object-oriented.
> This would only be compatible with object oriented languages.
Even then, it's only compatible with an implementation that either implements or stubs all the classes that a given STON body references. I can see where this makes sense for interop among Smalltalk environments with enormously complete standard libraries, where everything likely to be referenced in an arbitrary STON blob is available, but for interop among implementations in multiple languages, it's a no-go unless either:
- STON use is limited to a well-defined subset implemented by all parties in the interaction, or
- all languages use STON parsers which support automatically stubbing (ignoring, etc.) classes specified in content but which aren't available in the parsing context, or
- all parties in the interchange provide custom-implemented and probably dangerously incomplete translation layers between STON and the rest of the implementation.
That said, there are a couple of things here that I really like. I was about to say that, since es6 has a native symbol type, it might make a lot of sense to include symbol literals in a new version of JSON - but I've just taken the time to actually examine es6's symbol implementation for the first time in detail, and...well, I'm not sure precisely what it is, but I'm quite certain it's not what it claims to be, and its justification for even existing is gravely in doubt. That's pretty special, and it also means that STON symbols wouldn't even make sense in the context of es6, so never mind. The internal references in STON are pretty neat, too, but it'd be a hairball for any parser to implement and pretty useless unless every parser implements it, so never mind that too.
Oh well. If I weren't accustomed to compromise, I wouldn't spend so much time writing Javascript, would I? I will say, though, this "symbol" business really depresses whatever enthusiasm I had for deep-diving the post-ES5 variations of JS. If they're so far off the mark with something as trivially simple as symbols, God alone knows how badly they'll have handled the parts that are at all complex.
> only compatible with an implementation that either implements or stubs all the classes that a given STON body references.
Don't see why that would be the case. You can easily ignore the class info and then interact based on arrays/dictionaries. You just don't get the benefits.
