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
