[Libre-soc-bugs] [Bug 1094] insndb instruction database visitor-walker is needed
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Sun Jun 4 14:57:02 BST 2023
--- 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
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
* 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
> 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
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.
More information about the libre-soc-bugs