[libre-riscv-dev] [Bug 64] data handling / io control / data routing API needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=64

--- Comment #24 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #8)

> > * first_child can be merged into children in the constructor,
> >   making children_tuple redundant
> ok. I had it to enforce at least 1 child.

 [see below...]

> > * use of a tuple and the forced requirement that the tuple be an array
> >   of CombSegs is a design-flaw hard and unnecessary limitation.
> the *children arg is already a tuple.

 [...]

> >   simply passing in *children and assigning them to __children will
> >   allow developers to pass in anything that is iterable.  generators,
> >   __iter__-objects, tuples, lists, sets, dictionaries (iterating a
> >   dictionary returns its values) and so on.
> you can do that already by calling CombChain(*iterable)

 yes... except... that's... ok, there's several aspects to this.

(1) in some ways, abuse of a function is not really Your Problem
    (as the developer).

    think of it this way: if the function's called with the wrong
    number of arguments (zero), it's going to barf (throw an exception)
    if you don't have a check, and it's going to barf (throw an exception)
    if you *do* have a check.

    therefore... um... save yourself some typing... and don't bother
    checking!

    now, if this was a statically-typed language, this situation just
    wouldn't happen.

    however, this "bug" will in no way be detected by pylint or anything
    like it... so just accept it, roll with it, and save the typing.

    less code is better.

    however... see beloW (at end)

(2) if you can save yourself some typing by not coding "defensively"
    you can *also* save yourself some typing by not having to (unnecessarily)
    construct a tuple.

(3) if extra arguments are needed (which they are: see specallocate,
    i updated the docstring to explain why it may be needed), it gets...
    confusing.  specallocate (a boolean) *might* be accidentally included
    in the *args (either visually on reading or in actual code)

(4) *args is typically used to pass in *disparate* (variable numbers of)
    arguments, like this:

    def fn(*args, **kwargs):
       if len(args == 2):
           x, y = args
           z = "a default string"
       elif len(args == 3):
           x, y, z = args

    although, what you're supposed to do, obviously, is have z in the
    keywordargs.

    in this particular case, however, you *know* that the children is
    a variable-length list.

so... it's kiiinda abusing the *args paradigm, it's not really what
it was designed for, it costs CPU cycles, and places limitations on
what the developer can (has) to do, and could be confusing.

anyway.

you'll see, despite all that, i did add assertions on StageChain's
children list argument.  the reason is, the error (the exception)
may occur further into the development of the code, i.e. not *at*
the point at which StageChain is used.

this is a valid / legitimate reason for having the assert check.
however... overloading the *args capability of python... no so much.

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