On Thu, Jun 12, 2008 at 11:26 AM, Gabe Black <[EMAIL PROTECTED]> wrote: > 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.
Seems reasonable to me... I don't remember why we went with the current syntax instead of that... Nate? > Gabe Black wrote: >> 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 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? 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). >>> 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... >>>>> 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... Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
