Hi Junio, On Wed, 13 Nov 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> Regardless of the language the scripted version was written in, I > >> think the '--helper' approach is always the poorer choice between > >> the two [*1*]. It limits the modular decomposition to what suits the > >> original language, the impedance mismatch between the original and > >> target language forces us to unnatural style of inter module > >> communication, and the unnatural interface layer, which we know has > >> to be discarded at the end, must be written [*2*]. > >> > >> So, I'd prefer to see "because this is a better way in the longer > >> term" over "because the --helper approach would not work". > > > > Hmm. I feel distinctly unheard. > > The feeling is mutual ;-) Maybe I could take your comments more seriously if you acknowledged the fact that I am _very_ familiar with the vagaries of converting scripts to C. Like, very, very, very familiar. > > It may appear compelling, conceptually, to shun the `--helper` approach, > > but the more important reality is that it is the only one that makes an > > incremental conversion possible at all. > > > > It took an entire month of 60-hour weeks to complete the conversion of > > `git add -i`/`git add -p` to C, and only at the very end was I able to > > run the test suite with `GIT_TEST_ADD_I_USE_BUILTIN=true` and see it > > pass. > > Yeah, that is developer comfort, and of course it is nice to have > than not to have it. Comfort has little to do with it. Driving out bugs has a lot more to do with it. Which is the point I am trying to get across the entire time. > But compared to the downside impact to the quality of end result > that is inherent to the '--helper' approach, I'd prioritize the > quality of the end result over developer comfort. > > > It is indeed _in spite of_ the success of the `--helper` approach that > > we cannot use it here. > > As I do not see those past '--helper' ones necessarily successes, we > must agree to disagree here. Right. But if I recall, you never even saw the need for the conversions in the first place. Maybe you still don't? > In any case, the log message needs to express why _you_ ended up > taking the non-helper approach. Even though it is far less > relevant, compared to that, what other approach you instead wanted > to take, I do not veto you from having your own opinion. Okay. I will take that as an indication that I can go forward with the latest proposal. After all, I described pretty well, I think, why _I_ ended up taking the non-helper approach. Thanks, Dscho > >> [Footnote] > >> > >> *1* In only one case I would recommend using "--helper" approach, > >> though. When you are not expecting the developer to be able to > >> come up with a better split of the program into modules than how > >> the scripted version is, and you want to ensure that the > >> developer have something to show when they faild to complete the > >> project after N weeks. You are a more experienced developer > >> than an average GSoC student, and there is no pencils-down time, > >> so the exception would not apply. > >> > >> *2* In "git submodule" for example it was quite natural for the > >> module that gives a list of submodules with its traits the > >> program cares about to be written as a shell function that > >> writes the data to its standard output. And consuming modules > >> sit at the downstream of a pipe, accepting its output. When you > >> are writing these modules both in C, you wouldn't connect them > >> with pipe to carry the list of submodules, but a piecemeal > >> conversion using the "--helper" approach meant that there always > >> remained _some_ consumer that wants to read from the pipe, so > >> long after the module lister was rewritten in C, it still needed > >> to support a mode where it sends its output to the pipe, instead > >> of just passing an array of structures. > >> >
