Closing our barn door a little

[Walt Karas <wk...@verizonmedia.com.INVALID>]

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.

Re: Closing our barn door a little

[Walt Karas <wk...@verizonmedia.com.INVALID>]

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 <wk...@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
>
>

Re: Closing our barn door a little

[Leif Hedstrom <zw...@apache.org>]

> On Jun 11, 2019, at 6:13 PM, Walt Karas <wk...@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