20:09 <anuejn> what do you think about having a convention of defining the signals of a nmigen module as class variables?

20:09 <anuejn> is there anything stupid in doing so?

20:12 <ZirconiumX> Maybe I'm misunderstanding, but don't we do that already?

20:14 <anuejn> well till now i always used instance variables

20:15 <anuejn> ah but i made some fuckup in my head

20:16 <anuejn> if i have `class A: x = 10`

20:17 <anuejn> inst = A()

20:17 <anuejn> inst.x = 20

20:18 <anuejn> when i refer to inst.x now, am i refering to a instance variable x, which is shadowing the class variable x?

20:22 <vup> anuejn: yes I think thats how that works

20:23 <vup> also I think one of the main problems with using class variables is Signals whose properties (like width) depends on constructor arguments

20:24 <anuejn> well, we could just declare the type in the class variable to express the intent that this is a public facing signal

20:24 <anuejn> but you are right, that this is not ideal

20:25 <anuejn> since we also dont have "rich" signal types atm, which could express direction or size

20:33 <vup> yeah, currently I don't really see a benefit compared to adding a docstring, which seems a bit clearer to me

20:44 <awygle> If you use class variables you'll get the same instance of the variable each time you elaborate an instance of the module

20:44 <awygle> Which is almost certainly not what you want and may break nmigen? Idk haven't tried it