typisch 0.1.5 → 0.1.6
Sign up to get free protection for your applications and to get access to all the features.
- data/README.md +50 -16
- data/lib/typisch/version.rb +1 -1
- metadata +4 -4
data/README.md
CHANGED
@@ -9,33 +9,36 @@ and semi-structured data serialization languages -- Ruby, Python, Javascript, YA
|
|
9
9
|
|
10
10
|
## What distinguishes it?
|
11
11
|
|
12
|
-
It aims to be more than just an ad-hoc data validation library; rather, a proper type system
|
12
|
+
It aims to be more than just an ad-hoc data validation library; rather, a proper type system.
|
13
13
|
|
14
14
|
This means that it's able to do more than just validate data; it can settle questions phrased in terms of the
|
15
|
-
schemas themselves -- like "is this schema a subtype of this other schema?", or "compute the
|
16
|
-
these two schemas" -- in a well-defined and sound way.
|
15
|
+
schemas themselves -- like "is this schema a subtype of this other schema?", or (on the roadmap) "compute the
|
16
|
+
intersection or union of these two schemas" -- in a well-defined and sound (*) way.
|
17
17
|
|
18
|
-
This is nice, since if you're going to bother specifying
|
19
|
-
|
20
|
-
|
18
|
+
This is nice, since if you're going to bother specifying types for your data (as opposed to just writing
|
19
|
+
some validation code), you're probably doing so because you want to be able to reason statically about the
|
20
|
+
structure of the data. Having solid foundations makes that easier and more pleasant.
|
21
|
+
|
22
|
+
(*Sound with respect to an idealised data interchange language; in ruby there may be some minor differences:
|
23
|
+
sometimes ruby fails to distinguish between representations of two types, eg Tuple vs Sequence;
|
24
|
+
sometimes ruby draws ruby-specific implementation distinctions, eg Time vs DateTime or String vs
|
25
|
+
Symbol, which the Typisch types not to care about)
|
21
26
|
|
22
27
|
## As a type system, it features
|
23
28
|
|
24
|
-
- Record types with structural subtyping
|
25
|
-
|
26
|
-
- Tagged union types (
|
27
|
-
- Equi-recursive types, eg
|
29
|
+
- Record types with structural subtyping, and nominal subtyping based on a hierarchy of type tags (which
|
30
|
+
in ruby is based on the subclassing / module inclusion graph)
|
31
|
+
- Tagged union types (support for untagged unions was experimented with and may return to the roadmap at some stage)
|
32
|
+
- Equi-recursive types, eg `Person {parent: Person}`, which can be used to type-check cyclic object graphs if required
|
28
33
|
- Parameterised polymorphic types for Sequences, Tuples and other collection types
|
29
34
|
- A numeric tower with subtyping for the primitive numeric types
|
30
|
-
- Refinement types like "
|
31
|
-
- Decidable subtyping for all the above
|
32
|
-
- Ability to compute unions and intersections of types
|
35
|
+
- Refinement types like "String of at most 10 characters", "String from the following set of allowed values" etc, with more to come
|
36
|
+
- Decidable subtyping and type-checking for all the above
|
33
37
|
|
34
|
-
If that sounds
|
38
|
+
If that sounds powerful, bear in mind there's one very common type system feature which it *lacks*: function types, or typing
|
35
39
|
of code. Typisch only cares about typing data, which makes its life significantly easier.
|
36
40
|
|
37
41
|
Usually type systems for data are called 'schema languages', their types 'schemas', and type-checking 'validation'.
|
38
|
-
Forgive me if I use these terms somewhat interchangeably here.
|
39
42
|
|
40
43
|
## Semi-structured data and subtyping
|
41
44
|
|
@@ -50,6 +53,37 @@ Structural typing provides a rather nice way to describe these subsets, as *supe
|
|
50
53
|
|
51
54
|
So, a good notion of subtyping seems useful for a type system designed to cope well with semi-structured data.
|
52
55
|
|
56
|
+
## Type-directed (partial) serialization
|
57
|
+
|
58
|
+
A big part of the motivation is to support type-directed serialization into data interchange languages like JSON,
|
59
|
+
YAML, XML etc.
|
60
|
+
|
61
|
+
A deficiency in many serialization frameworks is the lack of support for flexible customization of the depth to which a
|
62
|
+
large object graph is serialized, and the shape such a partial serialization takes. Eg one may want:
|
63
|
+
|
64
|
+
- Different 'versions' of the same object which include or ommit different subsets of its properties
|
65
|
+
- Different versions of sub-objects to be used within a parent object, including when they appear within sequences, unions etc
|
66
|
+
- Just a particular slice (eg the first 10 items) of a large sequence of objects to be serialized
|
67
|
+
|
68
|
+
Typisch supports all these and more, via structural supertypes for object types, *and* for sequence types.
|
69
|
+
Structural supertypes for sequences are 'slice types', specifying serialization and/or type-checking of
|
70
|
+
only a particular slice of a sequence.
|
71
|
+
|
72
|
+
At present there is only basic support for serialization to JSON, and some details which are not part of the
|
73
|
+
JSON spec (like how type tags are serialized) need to be configured.
|
74
|
+
|
75
|
+
When serializing in JSON you need to avoid using unlimited recursion depth in the types and values being
|
76
|
+
serialized, as JSON doesn't support cyclic references.
|
77
|
+
|
78
|
+
Support for YAML would be nice to add, which provides better support for type tags, and for serializing cyclic
|
79
|
+
structures natively.
|
80
|
+
|
81
|
+
XML would be nice too, although would probably require more configuration for mapping, as its markup-based data model
|
82
|
+
isn't as close to that of Typisch and most dynamic languages.
|
83
|
+
|
84
|
+
Further down the roadmap, there is a lot of potential to compile fast serialization code (in Ruby, Java, C?) from a
|
85
|
+
particular type.
|
86
|
+
|
53
87
|
## Why Typisch?
|
54
88
|
|
55
|
-
Well, it combines Type and Schema. It's also german for "typical", as in "typical, another bloody schema language".
|
89
|
+
Well, it combines Type and Schema. It's also german for "typical", as in "typical, another bloody schema language".
|
data/lib/typisch/version.rb
CHANGED
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: typisch
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 23
|
5
5
|
prerelease: false
|
6
6
|
segments:
|
7
7
|
- 0
|
8
8
|
- 1
|
9
|
-
-
|
10
|
-
version: 0.1.
|
9
|
+
- 6
|
10
|
+
version: 0.1.6
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- Matthew Willson
|
@@ -157,7 +157,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
157
157
|
version: "0"
|
158
158
|
requirements: []
|
159
159
|
|
160
|
-
rubyforge_project:
|
160
|
+
rubyforge_project: typisch
|
161
161
|
rubygems_version: 1.3.7
|
162
162
|
signing_key:
|
163
163
|
specification_version: 3
|