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 > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
