[Libre-soc-bugs] [Bug 1094] insndb instruction database visitor-walker is needed

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1094

--- Comment #72 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #68)
> I think the users of API will have some difficulties differentiating which
> stuff comes from where, especially with nested data types (e.g. dataclasses
> or tuple-like or similar).

well, we are the users, and if we understand it (and, importanty, create
enough examples), then it's fine.  but also of course, documentation
comments etc. are also crucial.

this is compiler / language-translator technology, basically:
data-transformation.  it is always very tricky.


> Options are:
> 1. For dataclasses or dict-like, yield field names along with nodes. For
> tuples, yield index. Something else for others?

(for tuples and lists, and anything else iterable, yield the index, yes)


> 2. Have the types decoupled, so that by type it's possible to determine the
> origin. Seems kinda dumb and overkill.
> 3. Yield the node parent along with the node itself.

(3) i recall seeing in pyomo.


oh. i know a trick that can help: create the following:

* a "database printer to file-handle" Visitor
* a "database reader from file-handle" Visitor.
* a "database *comparator* Visitor.

then a unit test can be written which:

* prints out the entire database to a file
* reads the entire database from the file
* compares the database contents against the original

through the decoupling to a file we *will* know:

* firstly if the API looks sane,
* secondly if everything works, and
* thirdly have some absolutely fantastic (and complete) examples
  demonstrating how it all works.

then run it on:

* an instance of the Database class
* the Database class itself.

the latter might need a different comparator-Visitor

-- 
You are receiving this mail because:
You are on the CC list for the bug.