Split data encoding
data_encoding.ml had grown a lot, this MR breaks it into smaller, more manageable chunks. Note that the scope of this MR is only to reorganise the file into smaller chunks, further MRs will follow once this one has been merged in – as detailed below.
Changes and status
All modules build and all tests pass. The interface for
Data_encoding is kept fully compatible.
Data_encoding only includes module aliasing for the different components that have been split off. The exceptions to this rule are
- simple functions that depend on multiple components at once (
- simple aliases for components of some modules to keep the interface fully compatible.
Open question: abstract/concrete
'a desc should ideally be abstract to any users of the
Data_encoding library. This is currently not enforced by the module system: anyone can access
Tezos_data_encoding.Encoding which contain a non-abstract type definition for
Is it important? Is enforcement by code-review sufficient? Is it easy to do (with jbuilder/dune)?
These are possible improvements to make in the future. Please comment: Are they useful/nice/meh/useless/harmful? Are they urgent?
- Do not
include Encodingin the top-level module
Data_encoding. Users can simply use
- Remove the top-level aliases (
json_encoding, etc.) in favour of the component's equivalent value.
Descriptor. This follows the module's documentation: “This works by writing type descriptors by hand, using the provided combinators” and is clearer IMO.
- Improve documentation (especially that of the
- Improve the exception's documentation: what function can raise what exception, etc.