I prefer Nate's way too - members be _member, and accessor be member(). I half did this with my contextId()/cpuId()/threadId() changes just now. my "set" functions were still prepended with "set" though, didn't think of overloading.
Anyway, point is, I'm down. Lisa On Thu, Nov 6, 2008 at 2:16 PM, Ali Saidi <[EMAIL PROTECTED]> wrote: > I'm fine with it shifting to this method.... Too bad that C++ doesn't > have Objective-C like properties. > > Ali > > On Nov 6, 2008, at 2:10 PM, Steve Reinhardt wrote: > > > What's the convention in other objects? I'm fine with either approach > > (though I lean toward what Nate is suggesting); as with most style > > things, I'm more concerned with consistency than anything else. I'd > > be OK with this if it's part of a trend toward doing accessors in this > > style globally (in which case this convention should be added to the > > style page on the wiki). > > > > Steve > > > > On Thu, Nov 6, 2008 at 11:02 AM, nathan binkert <[EMAIL PROTECTED]> > > wrote: > >> So, Packet and Request have lots of functions called getFoo and > >> setFoo. That sort of style has always annoyed me because it requires > >> a lot of extra typing and space. e.g. > >> > >> /// Accessor function for the destination index of the packet. > >> short getDest() const { assert(destValid); return dest; } > >> /// Accessor function to set the destination index of the packet. > >> void setDest(short _dest) { dest = _dest; destValid = true; } > >> > >> Would there be major objections to changing this to: > >> > >> /// Accessor function for the destination index of the packet. > >> short dest() const { assert(destValid); return _dest; } > >> /// Accessor function to set the destination index of the packet. > >> void dest(short d) { _dest = d; destValid = true; } > >> > >> You can tell if it is a get or a set by how it is called. If people > >> hate this, we could keep the setDest() version and rename getDest to > >> dest(). > >> > >> I can see one major objection to this change being the impact that it > >> could have on people porting their own code forward to newer versions > >> of M5 after this change. That said, if we're going to be doing any > >> major changes to the memory system, now is the time to make this sort > >> of change. > >> > >> Nate > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev