Skip to content
100644 34 lines (25 sloc) 1.3 KB
44b126c @luqui Added a TODO file, documenting the brittleness of some of the current…
1 The type infrastructure, eg. RootType and the Data classes, are only as
2 portable as the Binary and Typeable instances. The latter in particular
3 is not terribly portable (it is even brittle under some innocuous
4 refactorings).
6 I can't think of any *provable* way to solve this, nor any fully
7 distributed way. But a decent solution would be to add a member to
8 Data:
10 class Data a where
11 desc :: DataDesc a
12 version :: String
14 With the requirement that two types with the same version are serial
15 compatible (versions should also be unique across types). Thus if you
16 make a change to the Binary representation, you are responsible for
17 updating the version.
19 There are a couple challenges:
21 * For existing modules, if we define version on their behalf, we will
22 have a hard time keeping up with updates. That is, the dependencies
23 of the package that defines these have to be pretty strict.
24 * For new modules, making sure that there are no name collisions.
26 There may be a better solution assuming an Udon package manager though
27 (since we can reference modules and ranges of modules directly).
7ecf1ff @luqui Implemented data-preserving DynRefs (the same way ExtRef does it) so …
29 ===================
31 The implementation of the main Udon library is too coupled. I don't
32 want to export the DataDesc constructor, the unsafe* functions about
33 ExtRefs, and a host of other things. Thoughtful cleanup is needed.
Something went wrong with that request. Please try again.