Mercurial > repos > public > sbplib_julia
comparison Notes.md @ 829:1de10f5b2008 operator_storage_array_of_table
Add some notes on the format of operator storage
author | Jonatan Werpers <jonatan@werpers.com> |
---|---|
date | Wed, 12 Jan 2022 13:07:43 +0100 |
parents | 1d166e7a9deb |
children | fe8fe3f01162 |
comparison
equal
deleted
inserted
replaced
828:ca182cbb8f49 | 829:1de10f5b2008 |
---|---|
50 way to filter based on values of variables. There filters could possibly be | 50 way to filter based on values of variables. There filters could possibly be |
51 implemented through keyword arguments that are sent through all the layers of | 51 implemented through keyword arguments that are sent through all the layers of |
52 operator creation. | 52 operator creation. |
53 | 53 |
54 * Remove order as a table name and put it as a variable. | 54 * Remove order as a table name and put it as a variable. |
55 | |
56 ### Parsing | |
57 At the moment the only parsing that can be done at the top level is conversion | |
58 from the toml file to a dict of strings. This forces the user to dig through | |
59 the dictionary and apply the correct parsing methods for the different parts, | |
60 e.g. `parse_stencil` or `parse_tuple`. While very flexible there is a tight | |
61 coupling between what is written in the file and what code is run to make data | |
62 in the file usable. While this coupling is hard to avoid it should be made | |
63 explicit. This could be done by putting a reference to a parsing function in | |
64 the operator-storage format or somehow specifying the type of each object. | |
65 This mechanism should be extensible without changing the package. Perhaps | |
66 there could be a way to register parsing functions or object types for the | |
67 toml. | |
55 | 68 |
56 | 69 |
57 ## Variable second derivative | 70 ## Variable second derivative |
58 | 71 |
59 2020-12-08 after discussion with Vidar: | 72 2020-12-08 after discussion with Vidar: |