ObjectHash presently uses the following single-letter identifiers for its types:
b: booleand: dictf: floati: integerl: lists: setu: Unicode string
In TJSON I have slightly different single-letter identifiers which express a slightly larger range of types, including binary data (see also #22), and have names that align with the JSON data model:
A: arrayO: objectS: setb: booleand: binary dataf: floating pointi: signed integers: stringt: timestamp
Note the use of a capital to denote a non-scalar type.
I think it'd be great to agree on a common set of tags. I began working on an ObjectHash-alike using these identifiers, but I'd definitely prefer to use ObjectHash itself if possible.
If ObjectHash were to adopt the TJSON identifiers outright, it would require the following changes (old => new):
d => Ol => As => Su => s
This would also free up d for use with binary data, which I think is a particularly nice thing to support (i.e. Unicode strings can be normalized prior to hashing, but binary data is hashed as-is).
ObjectHash presently uses the following single-letter identifiers for its types:
b: booleand: dictf: floati: integerl: lists: setu: Unicode stringIn TJSON I have slightly different single-letter identifiers which express a slightly larger range of types, including binary data (see also #22), and have names that align with the JSON data model:
A: arrayO: objectS: setb: booleand: binary dataf: floating pointi: signed integers: stringt: timestampNote the use of a capital to denote a non-scalar type.
I think it'd be great to agree on a common set of tags. I began working on an ObjectHash-alike using these identifiers, but I'd definitely prefer to use ObjectHash itself if possible.
If ObjectHash were to adopt the TJSON identifiers outright, it would require the following changes (old => new):
d=>Ol=>As=>Su=>sThis would also free up
dfor use with binary data, which I think is a particularly nice thing to support (i.e. Unicode strings can be normalized prior to hashing, but binary data is hashed as-is).