Skip to content

Support a canonical serialisation #4

@gisborne

Description

@gisborne

This is splendid. But there is a feature I didn’t see you discuss that would be very useful.

Very often, compound types would reasonably support multiple, correct, compatible expressions. A set would in practice be serialised as some sort of list probably, and this list could be in any order.

And that’s fine, and for various reasons, in different situations it might be most efficient to create different serialisations (adding values in the non-deterministic order they come back from the database, say).

BUT

In some situations, it is required to have a single, canonical representation for any given value. Usually, sorting suffices for this — if the aforementioned set is sorted in its list representation, assuming it is sorted in a deterministic and platform-agnostic way, then that is a good canonical representation.

An example of why you might want a canonical representation is to store the value in a deduplicating data structure: you can reference it by a hash of its canonical serialisation.

SO

Your encoding protocol should support a canonical true/false option.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions