Hacker News Reader

Comment by marianoguerra | Hacker News Reader

isn't there a way to extend the types to specify our own and register constructors for them? like transit?

otherwise we will be in the same place of json in terms of extension where our own types are second class citizens.

The problem I see is that everyone has their own favorite type systems. Functional people may consider sum types (tagged unions) indispensable, while OOP people might want their types to have notions of inheritance. Another functional programmer might want existential quantification, higher-kinded types that most people outside the functional niche have never heard of, but a lisp programmer might want actual code as data (quote/eval) so the type has to involve functions, etc. Extending the types beyond the basic primitives is difficult because there are so many different ways of doing that.

it's not about specifying a type system, just letting users specify a tag for a type and then register a constructor for that tag, then inside it you can have whatever type system thing you like, the serialization format doesn't care, for example {"#Some:myOption": "s:value"}, the decoder will call the constructor registered for Some passing the value and not care about your type system.

Agreed. Just adding some fixed types doesn't really help that much.

Something like EDN for JSON would be cool: https://github.com/edn-format/edn

Isn't Transit basically EDN for JSON in that it adds types and whatnot, and encodes to JSON?

Or do you mean, you want a format that's sort of halfway between EDN and JSON?

transit works great except that it's unreadable with current tools (for example browser devtools or attaching listeners to kafka).

I know it's a tool problem but I don't see the whole world embracing transit.

If this format gets adopted with extensible types we get a readable format that has what transit provides and if there's no tooling support we can still read it with standard json tools or none at all.

Transit is unreadable exactly because it has to work around the limitations of JSON (like string-only keys) to deliver its primary features: true maps, tagged collections etc. TJSON only has tags for primitives, so yeah, it's not much different from JSON this way, the tooling is happy.

> Just adding some fixed types doesn't really help that much.

It brings the set of scalar types you can express in a JSON message on par with other serialization formats like Protobufs:

https://developers.google.com/protocol-buffers/docs/proto3

We could just write a JSON Schema for it. It allows you to specify a "format": http://json-schema.org/latest/json-schema-validation.html#an...

So you can write a schema like: {"type": "string", "format": "email"}

or: {"type": "integer", "format": "uint64"}

There's no spec for what is allowed as a "format", so you have to decide on your own values and write your own validators, but someone could come up with a standard spec for this. Swagger formally specifies some values of "format" in this document: http://swagger.io/specification/

The purpose of TJSON is to be self-identifying and schema-free. If you want a schema, use Protobufs or the myriad JSON schema languages.

I don't want a schema, I want to preserve types between serialization and deserialization thus avoiding conventions or having to specify those types "out of band", the same way you want to make it clear that an int is an int and a date is a date, I want to tag an object to tell that that object is a city, a person or something else, each program should register a function to rebuild the actual object but at least it's not a convention anymore.

Reply on news.ycombinator.com