lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Preserving configurable settings after GUI test


From: Greg Chicares
Subject: Re: [lmi] Preserving configurable settings after GUI test
Date: Thu, 12 Jul 2018 18:07:44 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 2018-07-10 23:39, Vadim Zeitlin wrote:
> On Tue, 10 Jul 2018 22:54:40 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> > 1. Make private configuration_filepath() function public, i.e. a 
> (static)
> GC> >    member of configurable_settings.
> GC> > 2. Make configurable_settings copy ctor and assignment operator public 
> and
> GC> >    implement them.

We discussed refinements (2a, 2b), but they all require implementing
those special member functions, either as such or under different
names. But I just think it's simpler and safer to prevent them from
existing at all.

> GC> 4. Right now, we have
> GC>     void save() const; // public
> GC>     void load();       // private
> GC> and we could add overloads that take a nondefault filename. That seems
> GC> easy enough, especially because the implementations are one-liners.
> 
>  I like the simplicity of this, although it's not quite as simple as
> implied above because we also need to add the (optional) filename argument
> to instance() and the ctor.

It's no longer a singleton if instance() takes a filename argument.

> GC> I'm not sure which of {1, 2a, 4} I like best. What do you think?
> 
>  My order of preferences would be [2b, 1, 4], but the differences between
> all of them are small and I could live with any of them.
[...]
> GC> Here's my implementation of 1:
> 
>  The patch is a bit difficult to read because of moving around
> default_calculation_summary_columns(), but I think it's perfectly fine. And
> this would be definitely sufficient for the testing code to do its job. So
> if you don't want to spend any more time on this, please do commit it.

Finding objections (above) to the others, I went ahead and committed 1.
I could have broken it into several commits to make the diff more
readable, but that didn't seem cost-justified.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]