On Wed, May 29, 2019 at 9:34 PM Ricky Teachey firstname.lastname@example.org wrote:
Seems to me that namespace collisions are a possibility no matter what namespace you are working in, right? If you are in the global (module) namespace, and use up a, b, and c, that doesn't seem any different to me than using up ns.a, ns.b, and ns.c.
I am talking about each function definition, which when using this approach, effectively has to have its own namespace. e.g. at each of the function start:
def process(self): ns = HDL() ns.x = 3 ns.y = 4
def another_process(self): ns = HDL() ns.x = 5 ns.y = 6
Compare with this:
def process(self): x = Signal(width=32, value=0) y = Signal(width=16, value=0)
def another_process(self): x = Signal(w=32,v=0) y = Signal(w=8,v=0xFF)
Where should the signal attributes go for the namespace case? hmmm ... or maybe one namespace for each and every signal like this:
def process(self): x = HDL(w=32,v=0) x.signal = 5 # only one signal or one type of signal allowed for each name space! y = HDL(w=8,v=0xFF) y.signal = 6 # ...
You see, eventually this is not better than just arbitrary object and use obj.next = 5 ...
I really think the separation of declaration and use ... is sometimes important (you don't have to be forced to use it, but you'd better be able to use it).
In fact, you could say it expands your namespace. You can have multiple HDL namespaces and interact between them without any problems:
# these will be descriptors that store Signal instances
ns1.x = 1 ns2.x = 2
# you can combine them into another namespace
ns3.x = ns1.x+ns2.x
# or into an existing namespace
ns1.y = ns1.x+ns2.x
# or put them into a data structure
x = [ns1.x, ns2.x, ns3.x]
# and pull them back out again:
ns4.a, ns4.b, ns4.c = x
Behavior is preserved in all cases.