Yeah looks like you're right. I thought it might be less work to convert data members first to read-only rather than directly to private/protected. So I experimented with the hdr_info field in the State struct in the HTTPTransact class ( https://github.com/apache/trafficserver/blob/master/proxy/http/HttpTransact.h#L703 ). But I get 592 compile errors if I make it private, versus 809 if I make it read-only with the template.
On Wed, Jun 12, 2019 at 1:45 PM Leif Hedstrom <zw...@apache.org> wrote: > > > > On Jun 11, 2019, at 6:13 PM, Walt Karas <wka...@verizonmedia.com.INVALID> > wrote: > > > > I'm wondering if we should add this template to our core utilities: > > https://godbolt.org/z/4X-5wR . We could use it to conduct a gradual > > campaign of "creeping encapsulation", to pull up the pants of our many > > classes with (often lots of) public data members. If a class X had the > > data member 'int xyz;', for example, you'd change it to 'ts:ROData<int, > X> > > xyz;' and compile. Read accesses of xyz would (I think) generally compile > > fine, you'd only have to change the write accesses. > > > IMO, if we’re going go through these classes and fix them (which we > should), why not fix them properly with public/private/protected and > getters/setters? I agree that we are too frivolous with “public” members, > but not convinced we need to have public “RO” members (the common pattern > being private and getter’s, no?). As a bonus, debugging getters/setter’s is > really useful. > > Ciao, > > — Leif > >
