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 ;-)
Best,
Artur