lmi
[Top][All Lists]
Advanced

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

Re: [lmi] do_compute_column_widths_if_necessary()


From: Vadim Zeitlin
Subject: Re: [lmi] do_compute_column_widths_if_necessary()
Date: Wed, 25 Apr 2018 01:11:45 +0200

On Tue, 24 Apr 2018 21:53:51 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-04-21 20:42, Vadim Zeitlin wrote:
[...]
GC> >  As usual, I tried to keep this code as simple as possible because this
GC> > seems to be more in line with your preferences. Left to myself, I would
GC> > probably do something to ensure that columns can't be added after 
computing
GC> > their widths at compile-time, but this would make things more complicated
GC> > and so I don't think you'd agree. But while a run-time check is not at all
GC> > as good as a compile-time one, it's still better than nothing, I guess.
GC> [...]
GC> > GC> How can we be sure it's called exactly when necessary?
GC> > 
GC> >  I can write a prototype doing just this, but it would involve using
GC> > separate classes and move semantics and I was rather discouraged by your
GC> > reaction to my previous attempts to do it like this, so I'm not sure if
GC> > it's really going to be useful... would it?
GC> 
GC> This comes up often enough in our conversations that I'd like to say a
GC> few general words about it, even though I'm not sure whether they're
GC> really applicable in this case.
GC> 
GC>   Imperative logic + entropy --> spaghetti code
GC>   Inheritance metalogic + entropy --> lasagna code

 FWIW I didn't intend to add any inheritance to this code, I don't see how
would it help. By "separate classes" I meant a separate class for
constructing the columns and another one, obtainable from the first one
once and once only, for accessing them. This would still be more complex,
but you'd definitely be able to follow the logic step by step...

VZ


reply via email to

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