Refactor method CSV

[JJ]

Not that we should clean-code it to 15 lines, but it's 400 lines long, lots of decisions in there, we should factor out common code and do a multi on $in, at least. Otherwise it's going to be almost impossible to fix stuff like #21
This might include also totally eliminate method csv, which only checks, and deletes, an arg, and does some stuff with meta which I don't really understand. Lots of is copy, too, which are really unnecessary.
That arg, also, should probably get out of the *%args pile and get a definition on its own.

[Tux]

There are several reasons for not refactoring:

• Easy to port from perl5 Text::CSV_XS
• Keep the code unchanged so the speedometer will be of value: if you change the code to be more effective or faster while refactoring, you might gain speed and get different numbers. (I know, not good enough a reason to not refactor)
• I do not have any problems with bigger code chunks (at all). I rather have a 400 line block of code that I understnd than 400 different files with the code scattered all around just because someone likes smaller code chunks. This is why I do not like Java, where it is common practice

I heard from @lizmat that there are plans to try to optimize next and continue where possible (them not being exceptions than). The code as is would be a wonderful demonstration of how that speedup works out.

Note that CSV parsing is a state-machine, and with all the options I support, getting "common code" out is harder than you think.

If there are things you don't understand, ask! I might be completely wrong too :)

[JJ]

Well, the thing with smaller code chunks is that they're easier to test and debug. I don't think a small jump in code speed will be a big deal, if we gain usability and evolvability.

[Tux]

At the moment I disagree: Text::CSV_XS and Text::CSV are written for performance. Losing performance is a big deal. Usability is on the other side of the API. Evolvability is something else, and I seriously doubt if there are may new ideas floating around in adding new features to Text::CSV, but please prove me wrong.

[JJ]

El jue., 2 ene. 2020 a las 7:56, H.Merijn Brand (<[email protected]>) escribió:

At the moment I disagree: Text::CSV_XS and Text::CSV are written for performance. Losing performance *is* a big deal. Usability is on the other side of the API. Evolvability is something else, and I seriously doubt if there are may new ideas floating around in adding new features to Text::CSV, but please prove me wrong.

Well, there's one thing that as far as I can see, is not in the original Text::CSV which is using the "file" argument as a synonym for either input or output. But that's not the main point; refactoring would imply simply keeping the current API, which is well tested and thus there would be no big problem to deal with it. WRT to performance, adding tests would check that, but in principle, divying up a big method into many tiny would allow the JIT to optimize the call graph; converting "ifs" and "given" into multi would probably make it faster, not slower. Anyway, it's not something I'm going to get into immediately, except for the many files part, which is easy, in general.

[Tux]

Feel free to create a branch en see if there is noticeable speed-loss.
I know it will be hard, but please try to keep my style.

[JJ]

Well, Slang::Tuxic makes a pretty good job to keep it. :-)