[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 #38 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
> --- Comment #36 from Dmitry Selyutin <ghostmansd at gmail.com> ---
> Sorry, on the phone, so briefly.
>
> On **arguments: this is just a way to pass CLI arguments, nothing else. Some
> commands operate on a single instruction and I need to know _which_ one.

ok so here's a really important insight into Visitors: the pattern that they
use
has to be completely independent, such that a third-party does not have
to inherit from *any* of the classes used or created by anyone else.

> On tracking db, record and extra: yes the code is, at best, shitty. Basically
> what I want is "only filter some specific records to be visited, where record
> name matches the CLI arguments".

ok so you:

* create an entirely-new class, not having *any* inheritance
  from the *entire* set of code created so far;
* have its constructor store the records; def __init__(self, *args): self.args
= args
* create an instance of that object
* pass it to the walker-function which performs the traversal.


> I don't know how to do it, because visitor
> expects all records to be visited. Another option would be to pass "parent" as
> part of arguments for each visit method (e.g. Record.visit might get db too,
> and VisitableExtra would have db and record in its visit method). But this can
> be somewhat clumsy too.

again: you create an entirely-new class, which has *no* inheritance
at all from the entire set of code created so far,

> I'd like to keep the walking logic inside insndb and provide a way to caller to
> adjust how to handle the fact that something is traversed.

i think what you're describing is not a Visitor pattern, it's
something else.

> Callback-based way
> suffers from the same issue, though, so it's not specific to context manager.

and yet they are still used/developed, and python programmers the world
over continue to use/develop the visitor pattern.

context-manager is actually a bit of a problem because it 


(In reply to Dmitry Selyutin from comment #37)

> Ah yes, on MappingProxyType: that's the standard way of declaring a dict
> which cannot be changed in Python. Kinda RO-wrapper around dict.

so if that's envisaged as needed then there is something very wrong with
the Visitor API.

Visitor APIs *have* to be completely independent of the data.

now, if the *use* of the Visitor API needs that, then that's their
problem, but there literally should be no types, no data, absolutely
nothing, in the *API itself*/

the *only* thing it should do is:

* call a function/method at the start, with the object at current-depth
* in a for-loop:
  - call a child-begin-function with the sub-object (and index)
  - call a child-do    function with the sub-object (and index)
  - call a child-end   function with the sub-object (and index)
* call a function/method at the end, before dropping out to prev-depth

we can look at doing "polish-notation walking" and
"reverse-polish-notation walking" later.

can i suggest going back again to the pyomo visitor code, as the
complexities of Visitor-Walking are actually really hard to
express?

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/visitor.py;h=7ad025cd096

and no, "using some other project's code as-is" is not going to work
for this project, for many reasons.  one of which is "we do not want
additional dependencies" and another is "they make assumptions about
*their* code and *their* structure which bleeds into the modules"

additionally: Visitor API walker patterns are very compact but extremely
complex code, being developed usually over many months.

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