Am 24.11.20 um 19:52 schrieb Artur Tarassow:
Am 24.11.20 um 19:46 schrieb Riccardo (Jack) Lucchetti:
> On Tue, 24 Nov 2020, Sven Schreiber wrote:
>
>> Am 21.11.2020 um 11:58 schrieb Sven Schreiber:
>>> Am 20.11.2020 um 23:28 schrieb Allin Cottrell:
>>>> On Fri, 20 Nov 2020, Allin Cottrell wrote:
>>>>
>>>> The difference is between equation_system_bundlize() and
>>>> gretl_VAR_bundlize(): the former was converting to 1-based t1 and t2,
>>>> the latter not. The latter is now fixed in git.
>>>
>>> OK great!
>>> BTW I think some naming harmonization wouldn't hurt, either
>>> gretl_system_bundlize (with gretl_) or VAR_bundlize (without
>>> gretl_). I
>>> guess it could also just be system_bundlize.
>>
>> I'm trying to understand further the naming convention (or historical
>> path dependence). It seems the gretl_ prefix is quite common in
>> libgretl, and that actually the various functions starting with
>> "equation_system_" are the exception.
>>
>> My suggestion for harmonization is therefore to add the prefix gretl_
>> also to the systems-related functions. Perhaps
"gretl_equation_system_"
>> is a bit too long, and actually the "equation" part feels a bit
>> redundant IMHO. So what about this replacement rule for libgretl:
>>
>> *equation_system_* -> *gretl_system_*
>>
>> OK to apply?
>
> Of course I see your point and I'm all for anything that improves
> code consistency and legibility, but there's this nagging voice I
> keep hearing in may head that says "if it ain't broke..."
@Sven: Create a new branch, make changes, compile the code and run
some/ our test suites ;-)
@Jack: This is _exactly_ for what tests are: To verify that things
still work as expected after changes. And that's why I frequently
plead for much more tests ;-)
As this belongs to changes in the underlying C code, would the compiler
not throw errors in case of major distractions? A good linter (addon)
will also catch at leats some of the errors.
Artur