How about instead of Params.some_class the syntax would be Params(some_class) where Params is more like a class than a module? Then you could look up the information for the class you're dealing with without ever having to give it a globally consistent name.
Gabe Gabe Black wrote: > 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 >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >> _______________________________________________ >> 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 _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
