Any comments anybody? I have a few to add. First, as I went through the SimObject definitions and was taking out cxx_namespace, there were a few cases where the class name was still the same as "type", just in a different namespace. It's slightly redundant to have to put the class name in cxx_classname instead of just the namespace in cxx_namespace. Maybe cxx_classname should be able to optionally extend cxx_namespace?
For instance, cxx_namespace = "Foo::Bar" cxx_classname = "Baz" would be the same as cxx_namespace = "Foo" cxx_classname = "Bar::Baz" That might be nice if you want some sort of inheritance to put a bunch of things in the same namespace but to change their class names, or if you want to put a bunch of similarly named classes into different namespaces, using inheritance. I don't know if that would necessarily come up in a realistic scenario, but maybe it would with something like TLBs. One other thing I figured out was what "type" does. What it looked like is that it's what you use after "Params." to get the parameter description object/class/whatever for the right simobject. I'm sure that's not news to everybody, especially those that designed it that way :P, but I thought that might be a useful thing to know for everybody else. I also discovered that the way Params works now, as a flat dictionary of types like Enums, won't let you have as much naming freedom as python modules do with "import x from y as z" and "import x; x.y" and all that. I'm guessing there may be a way to make Params search in the current scope with some sort of __dict__ magic to find what class, for instance, Params.z.y mentioned previously goes with. This might be diverging so far from how python is "supposed" to work that it'd be hard for people to figure out how to use it, but on the other hand I'm not sure how else to do it. Then again I don't know if the language would even allow that, so it might be a moot point. In my mind, this is the biggest sticking point in getting rid of all the bottlenecks which make you collapse down to a flat namespace at some point. Gabe Gabe Black wrote: > I agree. There are three different naming mechanisms that I'm aware of > we need to work with, file names for the headers, python names which go > in modules, and C++ names which go in namespaces. If all names can be > hierarchical, which I think they should be, then there needs to be a way > to map the names into each mechanism. > > For python, the names can be flat but contained in modules which is I > think the python paradigm. That would hopefully be fairly > straightforward, but it might be complicated by the Params.xxx mechanism > and/or keeping information around in single namespace sorts of > structures like the dicts of Enums of different flavors. > > For C++, using namespaces should be fairly easy. Python objects know if > they're in a namespace already, so it shouldn't be too big of a deal to > prepend the class and function names appropriately to make it all work > out. We'd just want to make sure everything that ends up in C++, namely > enums, has a cxx_type (and/or cxx_namespace if that survives), and that > that gets reflected in it's definition and in pointers and all that. I'd > also want to know what -exactly- the "type" field is for, and why it not > matching the python class name causes it to break. Obviously somebody > knows this, but it was a problem I had (or seemed to have) earlier that > never really got resolved. If the names have to be the same and type > affects the C++ names somehow, then you might force things to be the > same in some way between mechanisms which can limit you're options. > > For files, there are a couple options I thought of off hand. First, you > could just use the file name of the containing .py for the .hh and bring > all that stuff in together. There are two flaws with that that I think > rule it out. First, the names of the .py files are unique, but only in > the scope of the directory they're in. The .hh files are in at most two > different directories, params and enums, so they're could fairly easily > be collions between, for instance, TLB.pys. Those are prefixed with the > ISA at the moment, but I think that's a little redundant and we might > want to change that. The second problem is that that creates a slightly > stricter coupling between the C++ and the python which would be nice to > avoid. > > The second option would be to put the C++ namespace hierarchy into the > header file names. That's going to be truly unique, unlike the names in > python which can be made locally unique through modules. We could for > instance either do that with directories a la java, which I don't > particular like the aesthetics of, or something like > namespace1.namespace2.class.hh. > > Gabe > > nathan binkert wrote: >>> What about making Enums recognize cxx_namespace too? That would be >>> pretty handy although I'm not sure how feasible. There seems to be a >>> global list of them that would probably get confused if there was more >>> than one with the same name, even if they were in separate modules. >> In general, I don't have a problem with namespaces. The >> implementation for this just needs to be better thought out. >> >> Nate >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
