[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 #37 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #20)
> (In reply to Jacob Lifshay from comment #8)
> 
> > >   the limitation of *all* data using *forcibly* being required
> > >   to go through the "Data" class instance is also a burden that
> > >   will result in significant user demands for "additional features"
> > >   on the Data paradigm, to add support for unanticipated
> > >   requirements.
> > We can override __subclasshook__ like in collections.abc.Hashable:
> > https://github.com/python/cpython/blob/
> > 1b5f9c9653f348b0aa8b7ca39f8a9361150f7dfc/Lib/_collections_abc.py#L84
> > 
> > This makes any class that implements the 2 abstract functions to be a
> > subclass of Data automatically (except that Data's methods won't be visible
> > unless actually deriving from Data).
> 
>  https://stackoverflow.com/questions/40764347/python-subclasscheck-
> subclasshook
> 
>  this looks alarmingly complex.  i have learned the hard way that complex
>  code that solves particularly difficult python problems using advanced
>  features of python is REJECTED BY THE USERS.
> 
>  technically it is correct... yet because the features deployed are so
>  hard to understand they simply do not trust it, as it requires extraordinary
>  skill and intelligence to debug if it goes wrong.
> 
>  i can honestly say that detested it when this was quoted to me.
> 
>  crucially: if the data API is "an arbitrary nested generator that
>  eventually yields derivatives of Value", i believe it would not
>  be necessary to even use subclasscheck/hook.
> 
>  does the generator approach make sense?
I had been planning on the Data API being a tree where the links were named,
similar to directories and files in a filesystem. This is similar to a subset
of C that has only structs and integers.

I think the nested tree of iterables makes more sense, though we will have to
be careful about member variable ordering and that dict-like objects return the
list of keys rather than values.

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