5 ms·

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 te

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.

cdmckay 10y ago
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 https://github.com/edn-format/edn
- fnordsensei 10y ago
  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?
  - marianoguerra 10y ago
    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.
    - unlogic 10y ago
      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.
- bascule 10y ago
  > 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 https://developers.google.com/protocol-buffers/docs/proto3
kccqzy 10y ago
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.
- marianoguerra 10y ago
  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.
tiglionabbit 10y ago
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#anchor104 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/ http://swagger.io/specification/
bascule 10y ago
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.
- marianoguerra 10y ago
  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.

cdmckay 10y ago

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 https://github.com/edn-format/edn

fnordsensei 10y ago
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?
- marianoguerra 10y ago
  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.
  - unlogic 10y ago
    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.
bascule 10y ago
> 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 https://developers.google.com/protocol-buffers/docs/proto3

kccqzy 10y ago

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.

marianoguerra 10y ago
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.

tiglionabbit 10y ago

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#anchor104 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/ http://swagger.io/specification/

bascule 10y ago

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.

marianoguerra 10y ago
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.