In general it would be nice to have some guidelines like this, but if in the immediate case we don't really need a namespace at all, I'm quite happy with that solution.
Steve On Thu, Mar 21, 2013 at 11:03 AM, nathan binkert <[email protected]> wrote: > We could have an Amba Namespace and a Device class, so it'd be > Amba::Device. > > We might also consider a different naming convention for namespaces. > > Amba_Device, amba_device, amba_ns, AmbaNS, NSAmba, AmbaNamespace, > AmbaStuff, AmbaIsThisNamespaceStuffUseful, > AmbaShouldWeUseMoreNamespaces? > > Nate > > On Thu, Mar 21, 2013 at 9:34 AM, Steve Reinhardt <[email protected]> wrote: > > Don't ask me why, but somehow I'm in a mood to actually fix stupid little > > things that annoy me instead of just letting them slide. (See the > swig_env > > debate.) Another one of those things I recently ran across is that most > of > > our I/O device classes end in 'Device', but a couple of them (PciDe and > > IntDev) end in just 'Dev'. Nothing a quick perl pie can't fix, right? > > > > Turns out that there's a complication in that there's an AmbaDev > namespace > > as well as an AmbaDevice class in src/dev/arm/amba_device.hh, so my nice > > perl substitution renamed the namespace to conflict with the class, and > as > > usual nothing is as easy as I thought it would be. > > > > Even disregarding the perhaps minimal value of my initial purpose, I'll > > posit that it's not good to have a namespace and a class whose names > differ > > only in that one is an abbreviated form of the other. So I'd like to > take > > care of this, but rather than just post a patch and see what happens, I > > thought I'd see if anyone cared how. Basically I see two options: > > > > 1. Get rid of the namespace and make the contents (a few const ints and a > > function) public static members of the AmbaDevice class. I tried this > and > > it works fine, with one side complication of the DPRINTF name() thing not > > dealing well with being in a static method, but I can handle that. > > > > 2. Rename the namespace to something a little more descriptive. > > > > Anyone care? Since I already did #1, that's what I'll stick with unless > I > > hear otherwise. If you prefer #2, please provide a suggested new name as > > well. > > > > Thanks, > > > > Steve > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
