> I was wondering why we had both 'type' and 'cxx_classname'... last > time I recall working on that code (before Nate finished the params > auto-gen stuff), the point of 'type' was to be the C++ class name. > When is the "Params.Foo" thing different from the Python class name, > and is there a good reason for it being that way? I'm not sure, but type was what was being used, not the class name. If we switch it to the class name, then we can probably use type and get rid of cxx_classname. There are several things going on here. One is that the python name and the c++ name can be different. Another is that there can actually be multiple c++ classes any one of which could be generated for one python class (think cache builder).
> Seems to me like we ought to be able to have a single parameter that's > the C++ classname including namespaces if any. I don't think that the > Python inheritance should affect the C++ classname implicitly (though > that's just a gut reaction, and if there are good counterexamples I'm > willing to change). I agree with steve. I'd like to just see something like type = "Foo::Bar::Baz" and have the code do the right thing. >>>> 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. > > Why don't you like the java directory hierarchy method? It makes sense to > me... Seems like it would be better to actually create directories for the files and do namespace1/namespace2/class.hh >>>>>> 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. > > Sounds reasonable to me... Agreed. I have a little bit of code working on cleaning this stuff up, and it's on my list. I'll get back to it probably in about a month when I whittle down my outstanding changes list. I'm motivated to fix this stuff because I think it's one of the messiest parts of the code and as I work on adding stuff to the SimObject base class (for event queues and dprintf), I'm going to want to clean up the python as well. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
